ASK HN: Best practices for storing Credit Card information

If you are processing credit card payments you are supposed to adhere to the PCI-DSS standards which do include encrypting Cardholder Data goto <a href="https://www.pcisecuritystandards.org/" rel="nofollow">https://www.pcisecuritystandards.org/</a><p>Get the self-assessment questionnaire and work through it.<p>Encrypting columns, rows or tables in your database is trivial, pgcrypto will do this for you if have postgres. Or you can hack something together w/ <a href="http://php.net/openssl" rel="nofollow">http://php.net/openssl</a> pretty easily. Whatever you do, don't try to write your own encryption routines, people will laugh at you and Moldovan teenagers will buy BMWs with your customers money.<p>Set up views so that non-finance personnel see the last four digits only, and those with a need to know can see the full PAN and have their accesses logged to an audit table that cannot be altered without superuser privileges.<p>Right now you can slide by, but in a few years your payment gateways and merchant banks are going to be insisting that even small processors have outside audits.<p>And according to the standard you should never store the cvv2 code, you should request it each time.<p>HTH

All the major card companies banded together and formed a standards group:<p><a href="https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml" rel="nofollow">https://www.pcisecuritystandards.org/security_standards/pci_...</a><p>Once you reach a certain volume of transactions you are required to comply. Doing so now is probably not feasible if you're small, but you can still take the spirit of the standard and do your best.

Credit card storage is scary. I was working with a company that had 20k credit cards stolen. Visa never called, nobody was notified, nobody ever found out. Only a small handful of customers who had just placed orders even suspected who it was. We actually tried to notify the merchant and credit card companies and they were like "huh?"<p>They don't store credit cards anymore.

you are definitely not supposed to be storing cvv numbers, in plaintext or otherwise. according to pci, you're not supposed to be storing or processing credit card numbers on the same machine (or even network, i believe) as your public web server.<p>if you are not sure how to handle this stuff, please, for the sake of your customers, use a company that does know how to do it. companies like braintree (<a href="http://www.braintreepaymentsolutions.com/" rel="nofollow">http://www.braintreepaymentsolutions.com/</a>) have a secure vault service that lets you store credit card information on their servers which you then access on a per-charge basis using a token.

I'm a developer for a large e-commerce site. We require users to input their credit card for each purchase (no save functionality). We store the credit card for the duration of the transaction. Which is usually a few seconds. The time it takes to do run an AUTH ONLY. During these few seconds cards are stored with 256bit encryption on a server not accessible by a public IP. We use the mcrypt library in PHP.<p>I understand you want to save the cards for future purchases, but you should definitely give customers the option to input their card every time if they so desire. If you dont need the card in the future, theres no reason to save it. Most processing gateways will return a transaction id which you can use to take processing actions in the future. You can run voids, refunds or settle payment. For our site we settle payment once we ship the goods and its all done with transaction IDs. The only thing we hang on to is the last 4 digits of the card number as a reference.<p>If you are going to store the card numbers use a good, well known encryption algorithm. Hashing isnt encryption, plus a one way hash will not work since you wont be able to recover the number to process.<p>Its important you become PCI compliant, especially if you are selling a hosted solutions to other businesses.

Don't. Use a gateway that can do this for you. Authorize.net does this pretty easily. The API is called Customer Information Manager and you can store not only CC, but billing info. Makes it easy to do lots of advanced stuff (it's a good option for recurring billing when you want lots of control).<p><a href="http://www.authorize.net/solutions/merchantsolutions/merchantservices/cim/" rel="nofollow">http://www.authorize.net/solutions/merchantsolutions/merchan...</a>

Like everyone else is saying, don't. It's a lot of responsibility and that's not your main business anyway. How about using something like Amazon FPS instead?

1) i don't believe that the act of storing the information in plaintext is illegal, but it could contribute to negligence suits if you mess up.<p>2) 2- or 3-TDES (<a href="http://en.wikipedia.org/wiki/Triple_DES" rel="nofollow">http://en.wikipedia.org/wiki/Triple_DES</a>) encryption; fully secure &#38; restrict access to whatever database you use and whatever system holds the database; SSL connection (obviously).<p>having said all of that, is there a reason why you're not using something like paypal, amazon FPS or some other payment service? they kind of take the work out of this stuff by providing a secure way of accepting payments, including recurring stuff with stored CC#s.

As everyone else has said, this is not a good situation. You don't want the overhead and risk of providing software security let along physical security for the storage of personal information unless your business model depends on shaving the fractions of a percent that it may save you in processing.<p>In all seriousness, get set up with a major processor and get on with your business. (PayFlowPro would work well for the recurring payments you seem to need as a feature.)

Our cc processor has a vault for storing cc info, so this stuff is never on our servers, so we don't need to comply with anything. Check with your cc processor they might offer a service like that too.

Simple. Don't.