Credit Card Data: What You Can and Can’t Store

We’ve all heard stories about credit card fraud, of staggering amounts being stolen from businesses both small and large, retail and online. We know how fiercely we should protect our own. Fraud losses can be devastating and unexpected as we transact in an era of increasing technology and innovation.

Compromising the security of our customers’ payment information is reputationally damaging and even the most well-equipped stores may experience fraud at one point or another. The most important thing is to reduce your risk as much as possible and make sure you follow changing rules in the payment card industry–and have a reliable merchant services provider that does.

Whether it be in your CRM system or for a recurring billing plan, there are legitimate reasons merchants need to keep identifiers of their customer’s payment method on file—better known as a “card on file”—but, what exactly are you allowed to store? And how are you allowed to?

First, make sure you are using payment card industry (PCI) compliant equipment and hardware, which is designed to handle payment data safely so you don’t have to. As a general rule of thumb, only store what you absolutely need to in addition to this.  

Cardholder Data: May be stored if rendered unreadable

Cardholder Data (CHD) includes the 16-digit primary account number (PAN), cardholder name, service code, and expiration date. You may only store certain elements of CHD according to PCI rules, and it can only be stored for a “legitimate legal, regulatory, or business reason”.

There are 12 PCI DSS rules and rule 3 focuses on methods to safely store CHD. Here is a summary of acceptable methods:

Hash functions

• These are simple index markers that flag records in a database where sensitive data is actually stored (in another secure form).

Truncation

• Also known as masking, this removes segments of data, such as showing only the last four digits or only the first six digits of a PAN. No more than the last four or first six may be shown in this method.

Encryption

• An algorithm combines sensitive plain text data with a random key that works only once.

Cryptography

• Formulas that make plain text data unreadable.

Sensitive Authentication Data: May never be stored

PCI requirement 3.2 states that Sensitive Authentication Data (SAD) can never be stored after authorization is completed. This means that the data can be collected for the purposes of authorizing a payment transaction, then it has to be deleted. It includes magnetic stripe data, PIN and PIN blocks, and card verification codes.

What are Card Verification Codes or Values (CVC or CVV)?

CVC or CVV are types of data necessary to authorize digital payments and refer to the three- or four-digit number typically printed on the back (but may be on the front) of a payment card. Depending on the card brand this might also be called the CID, CVC2, CVV2, or CAV2.

CVV is a security feature that should be collected at the point of sale for online or phone order transactions, but may never be stored after payment authorization. The point is to make sure the card-not-present transaction is being made by a customer with the physical card on hand. Merchants don’t have to collect this every time for card on file or recurring payments.

How do you delete sensitive authentication data?

Don’t worry – Developers of payment solutions have to get PCI-approved before they bring to market software and hardware, and it must have secure, automatic deletion techniques in place. So, verify that your payment solution is up to date, then you just have to make sure you don’t store SAD in your own system. Encryption is not sufficient; all data must be properly deleted so that it can never be recovered.

What if a customer requests CVV storage?

This is prohibited according to PCI rules, and merchants may not grant customer requests to keep CVV or any PCI-prohibited card data on file after payment authorization.

Source