Storing credit cards - best practices?

What is the best practice for storing sensitive credit card information?

[ggmike]

I've recently been asked to develop an ecommerce site that will charge a subscription fee to customers. The system needs to store the credit card in a database so that users can log in and order extra subscriptions without having to re-enter their credit card information, and for the system to be able to charge them every month.

I'm wondering - what are the best practices for storing this type of information? Should a separate database be used for the credit cards, are they usually encrypted in some particular way, etc..

I know CC information is very sensitive so there must be some guidelines for keeping it safe, and maybe even some laws. Can anyone fill me in on this?

[FraudAdvisor]

GGmike,

Storing Card details is a touchy subject with all the Schemes.

Best practice minimums are:

- Store card details (i.e CC number, expiry) in encrypted form that then can only be read intoto by those with a "need to know" - in reality no-one. By intoto I mean any stored data should be masked for display i.e. 4494 ******** 21008. This maintains the integrity of the data but doesn't allow it to be compromised through copying from display screens.

- Store cardholder details (name, address, contact details) in a SEPERATE encrypted database with a unique reference identifyer linking the two.

Needless to say both DBs need to be behind a robust firewall with outbound traffic barred.

Also, and this is critical, NO sensitive data should be stored (ie CVV2, CVV or CID values) - that is an instant "removal of service" compliance issue.

If you need more background drop me a line.

[Corey Bryant]

Also make sure that you do not display the credit card number on the screen once it is entered. In eight states it is against the law & will become standard soon.

You should check out the Visa CISP requirements also

-Corey

[ggmike]

Thanks for the advice guys.

Can either one of you point me to more information regarding storing the CVV or CVV2? I believe the merchant account needs this information to charge the card, is this not true?

[FraudAdvisor]

GGMike

You may capture the CVV/CVV2 *solely* for the purposes of forwarding that value to the acquirer as part of the auth request message. At the point the auth request is made the CVV/CVV2 value *must* be completely and irrevocably purged from the merchant system.

If you or the merchant you are working with store the CVV/CVV2 value you risk losing your acceptance facility but more importantly you are directly contributing to a weaknening of the defence these digits offer Merchants and Issuers alike.

CVV/CVV2 is critical in defending against CreditMaster type attacks so please ensure you ensure the continued efficacy of the program.

If in doubt partner with your merchant's acquirer to understand their requirements - alternatively, a Corey has pointed out, use CISP (in the US) find it at: [usa.visa.com...]

or AIS if you are outside the US. Either are useful as a benchmark for best practice - although they can seem quite onerous.

To recap - you don't need to store the CVV or CVV2 value as in most cases the issuer will either straight deny a bad value or feedback via the auth response message that the value was incorrect. You need to ensure that whichever way a bad value is reported to your client they cannot continue with the sale.

Hope this helps.

[ddent]

It really depends on how much of a target you are. The more of a target you are, the more careful you need to be.

Consider Amazon - from what I understand, they have a computer (or computers) they call the cc motel -- the numbers check in, they don't check out :).

It's connected solely via a serial cable to the rest of their system, which makes it extremely feasible to do a careful security audit of the interface.

When they get a number, they send it over to the ccmotel, along with a unique identifier. They then store the unique ID, and send that ID over to the CCmotel whenever the card needs to be authorized/charged.

Daniel

[Corey Bryant]

Sorry I cannot remember what links can be posted & what links cannot be posted on this board. I would just rather err on the side of caution & not post them

There are also some companies and gateways that will store half the CC number on their server & half on yours

-Corey

[minnapple]

I have custom ecom system.
Once the order has been processed, the cc number is deleted.
Due to liabilites, I would not consider any other option.
I also have my clients sign an agreement that they are responsible for any open cc numbers.
If they are slow to process orders, that is their liablity not mine.
I try to secure all data the best I can, but any data can be compromised.
If they want to store cc number, tell them they should seek a consultant to aquire a proper insurance policy.

[HughMungus]

This might be a dumb question: why not just use Paypal? Customers don't need an account to make a credit card purchase anymore.

[Corey Bryant]

This might be a dumb question: why not just use Paypal? Customers don't need an account to make a credit card purchase anymore.

That is only for United States merchants with the proper account.

-Corey

[Later2]

Corey
I'm in the UK and have just started using PP in peference to WorldPay - and it is the case for me. I now only use WP as a kind of back-up. PP has come a long in the last few years.

[uksports]

"I'm in the UK and have just started using PP in peference to WorldPay - and it is the case for me. I now only use WP as a kind of back-up. PP has come a long in the last few years"

Later2, if you get a payment from an unverified PayPal user, how do you go about verifying the payment - with WorldPay you have AVS and CVV, with PayPal you have - nothing?

[Later2]

Hmm
Good question. Does anyone else have a view on this?

[Corey Bryant]

Well with Paypal, you are using their merchant account & it should be up to them to do AVS & CCV. Of course a lot of times, this does not happen with Paypal. With your own merchant account, you do have a lot more control over this. I would love to see Paypal implement more fraud measures but so many organizations think that just the archaic AVS procedures are enough.

-Corey

[Namaste]

we store the card data on a seperate server that is not connected directly to the Internet. This server is accessed using a "tunnel" from the main server. This makes it v. diff for anyone who might gain access to our server to access the card database

[Namaste]

Also, and this is critical, NO sensitive data should be stored (ie CVV2, CVV or CID values) - that is an instant "removal of service" compliance issue.

well, amazon should be barred then. They store all values in their "wallet", and when making repeat purchases, you need not enter in any values again.

[Corey Bryant]

They might not store the CVV. These digits do not need to be passed to the gateway to complete a purchase.

-Corey

[ddent]

And furthermore, who knows, with their volume, they may well be connecting to visanet directly...

[Rice]

On our site we delete encrypted cc numbers after 30 days. Now this means registered customers do have to renter this data with return visits/purchases (unlike Amazon), but we think this practice outweighs the convenience for the customer in terms of security. The 30 days is generally a reasonable time in which most order adjustments will need to be made. Of course, we keep the number in a non Web environment for later transactional adjustments such as credits on returns which frequently occur after 30 days, at least in our business.

[Consulting4thefuture]

Can't store them really. You need a Cisp provider U.S. Try Trustcommerce, they have some great products and it's the best I've used so far.

Cheers