This article is the second one in a mini-series describing recommendations to be considered by merchants interested in attaining PCI compliance. In this installment we are going to look into the reasons behind payment card data storage and possible solutions that make PCI audit more simple.
If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.
Reasons behind payment card data storage
There are several reasons for payment card data storage:
- for reporting purposes and to look up previous transactions
- for issuing of refunds
- for repeat purchases and recurring billing
Let’s take a closer look at each of them.
Payment card data storage for reporting and transaction lookup
The question to consider here in terms of payment card data storage is whether it is really necessary to store credit card numbers for future transaction lookup.
If a business is storing the info for reporting purposes without actually doing anything with the card number, it can just store a part of that number (for some merchants it might be sufficient to store just the last 4 digits, solely for identification purposes).
For lookup purposes by full account number merchants can use one-sided hash (information on hashing algorithms can be found here. A common way is to use SHA-256 hashing function with multiple iterations and salt to ensure that the data is hacker-proof.
The hash value is unique, the number of iterations is difficult to guess, and the salt is difficult to crack. Even if the hashing algorithm was determined, the number of iterations established, and the salt guessed, it would still take a considerable amount of time to decode card numbers using brute force approach.
Generally, storage of the last 4 digits and one-sided hash is considered acceptable, but the final “verdict” will depend on your specific auditor.
Payment card data storage for issuing of refunds and transaction settlement
In some cases, merchants would process credit card transactions and store payment card data in order to be able to issue a refund (return money) on the card if the cardholder returns merchandise. Sometimes, certain processors will require full credit card information to settle transactions at the end of the day.
In both cases (refund and settlement) merchants need to consult with the current payment gateway or payment processor to see if there is an alternative option to return money or to perform settlement.
If a merchant needs to return money to a customer, many present-day processors and gateways support refund operation using reference number. When the original sale transaction is processed, a reference number is returned back to the merchant. Subsequently, it is possible to issue a refund passing only the reference number back to the processor, and effectively returning money for that transaction without supplying the original credit card number.
Those, experiencing the problem around settlement (usually, associated with terminal capture) should consult their current payment gateway and see if there is a host settlement (capture) option available that would eliminate the need for sending credit card information at settlement time.
Payment card data storage for repeat purchases and recurring billing
The most common payment card data storage solution for repeat purchases and recurring billing is tokenization. Instead of getting and storing the credit card number, businesses, wishing to have support for repeat purchases and recurring billing, are getting a token from a PCI-compliant tokenization provider. Thus, they can store a token instead of the card number, and reuse it in subsequent transactions\purchases, while reducing their PCI scope.
The concept of tokenization and respective options available to merchants for effective payment card data storage and PCI scope reduction will be covered in the next post.
Recommended to you
