Security of billing web application

SSL handles security of data while being transported.

So yes, you would certainly use SSL for your internet connections to be sure the data passing along the network is encrypted.

And remember that if you handle credit card information directly, your software will have to meet the security standards as discussed in the course. You might want to consider one of the third-party services for handling payment details for you.

Assuring that the data being sent is intended for the right user will be a matter for user authentication in your server's application. However the user's identity is determined, you still have to perform access control of what data is sent to them.

I haven't created any sites using AWS myself, but I'd bet they would only offer viable options for security there. Just be sure to compare the options and make a selection that fits the needs of your application.

For credit card processing you almost certainly want to use a merchant that provides javascript tokenization. Stripe has the best setup that I have personally come across. You can charge one-time payments and even store the card for future use by that user. The way it works is, you create a payment form on the site, but using a provided javascript library, the data is submitted directly to stripe. They validate the card data and if it succeeds, it will return to you a token. You then can submit the token to your application and use the token to trigger the charge or store the card. It is still up to you to write your application in a way that only allows the proper use to create charges against the right card(s). If your system is compromised, all you lose are the tokens, which only your stripe account is allowed to use. No card data is at risk.

As far as writing the application and using https, this is a pretty big task. To start with, you at least want to use 1-way hashing for passwords with an algorithm that has a parameter for how much computing power is used. I heard that you want to set it high enough that each hash function takes at LEAST a quarter of a second to run. The higher the better. This is so that if someone wants to attempt a brute force attack, they could only run 345,600 password in 24 hours. As long as the passwords aren't the super-easy-to-guess kind, the hacker can't attempt enough combinations to be a real threat. In the future when you upgrade your server the algorithm will run faster. You will want to adjust your computing power param to make sure it takes a while to hash each time. When you store the hashes it will contain the data of what the setting was at the time of creation (so you don't break your old passwords). However upon login, you can check to see if the params have changed and if a new hash needs generated. If it does you can re-hash it with the stronger encryption. You can only do this on successful login because this is the only time the server will 'know' what the right password is. Not sure what your language is, but here is the docs on PHP's version http://php.net/manual/en/function.password-hash.php

Another few things to consider that you might not think about right off the bat....

https is secure but only from the start of encryption to the point in the data stream where it is decrypted. So it's safe from eavesdropping (reasonably). But there are spots on the client's machine and on your server where the data exists in an un-encrypted format. An example of this is session data. Some setups write session data to plain text files. So be careful what data you put in your sessions! Another place you might not think about is your logs. GET data is typically included in plaintext logs. So if you are not POSTing sensitive data, the sensitive params might end up in your logs. Then there are cookies. If you are going to 'keep users logged in' using cookies make sure you have some encrypted way to verify the cookies were set by your server. Also, if there is any pages on your site that aren't secure, you are passing the cookies in an unencrypted manor which could be sniffed, faked, and used on pages with sensitive data.