After several years of coding applications that needed to process credit cards in real time as well as perform autorenewals at specified intervals, I've come up with a few best practices that I use as a habit.
Here they are: my accumulated techniques for working with credit card data on the web:
- Always pass credit card information via SSL (this includes information sent to the user's browser as well as that sent up to the server):
- Make all links to your credit card form begin with "https://"
- Within server-side code, ensure that credit card form pages are served and received via SSL before any processing takes place (ie, check your environmental variables for the use of port 443 and/or for HTTPS to be in use).
- Within front-end code, ensure that the form's
actionattribute contains an absolute URL starting with "https://"
- When coding a form input to get credit card data, include an
autocomplete="off"attribute in the tag to prevent the browser from keeping the credit card number in its autocomplete cache. - When displaying credit card numbers in the browser, all but the last 4 digits should be omitted or replaced with another character such as asterixes.
- Never display the user's security code in a browser (the security code, or CVV, is the 3 to 4 digit code from the front (American Express) or back (all others) of a card).
- When storing credit card data:
- Use strong encryption to encrypt the credit card number before storing it in your backend.
- Never store the security code in your backend. Its value depends on the presumption that the only way to supply it is to read it from the physical credit card, proving that the person supplying it actually holds the card.
- Within backend storage, I purposefully obfuscate the table name, column names, and data for the table where I store credit card data. If someone ever gets into my database, there's no reason I'm going to tell them "Hey, credit card numbers here!"
Comments (3)
August 30, 2007
11:01AM | #
I liked your posting. I'm a systems Analsyst at WorldatWork, nd we are looking at enhancing our shopping Cart application. In your oppinion, what are the plusses and minuses of maintaining credit card information in our database.
August 30, 2007
11:57AM | #
@Marco,
What are the pluses and minuses of maintaining credit card information in your own database? I'll tackle the minuses first:
- you're responsible for the security of the CC data in your own database, and therefore liable for any breaches in security where that CC data is stolen;
- you will need to maintain extra security measures for your database, such as special networking connections and firewall rules;
- finally, you'll want to be compliant with the payment card industry's PCI rules, which are extremely stringent.
The pluses are:
- You maintain the relationship with your client, and can easily track all of the transactions and other events that occur. If you're not hosting your own payment system, it will be more work to find out what they've processed successfully and when;
- You can change payment providers at any time and still retain control over your data, without worrying how to export it from one location and import it into another.
All in all, I think it's worthwhile to host your own CC data if you can handle the PCI security requirements. If you choose to host the data with a third party, just make sure that they have convenient ways for you to get transactional information on a regular basis. For instance, one provider I recently spoke with would have hosted all of our CC data and performed all transactions for us. They offer an API so that we could download all transaction histories on a daily basis to keep track of customer status in our own database.
July 18, 2008
2:04AM | #
1)Any body credit card back side there will be security code 3-digit number tell that number. (send the answer on e-mail)