NEVER keep all your customer’s Card Holder Data just because you can. The best practice is that you only keep card data if there is a good business justification for it. So, don’t keep them for clients who buy a product or service, but are unlikely to buy it again (e.g. a particular course) or buy other products within a reasonable period of time (e.g. if you are selling products that have a 10-year life expectancy).
There are two main reasons for keeping customers’ Card Holder Data:
1. Repeat business; where you want to make it as easy as possible for the customer to buy again by offering a “one-click” payment.
2. Recurring business, where the customer is paying for a subscription, usage, rent, etc. on a regular basis.
If you are keeping Card Holder Data, you can opt to keep them yourselves, but this will immediately put you in the highest category of PCI compliance (I have another post dealing with PCI). There are now plenty of offerings in the market from companies that can store the cardholder data for you. Some payment service providers even offer this for free.
Note: you should ALWAYS tell the customer that you are storing the Card Holder Data. Or alternatively, allow the customer to opt-in or opt-out of their Card Holder Data being stored.
If you do decide to keep the data yourself, please note that you can NEVER store “Sensitive Cardholder Data”:
For the Card Not Present environment this would be the 3D Secure Password and the four-digit CID(AmEx), or three-digit CAV2/CVC2/CVV2/CVV.
PCI DSS permits the storage of cardholder data providing compliance requirements are met. When stored on a database, the Card Number must be encrypted upon capture and not returned to plaintext. To identify cards securely, the first six (which is the BIN which stands for Bank Identification Number) and the last four may be displayed.
Before Saving the Card
We would recommend that you process a “normal” payment on a card to check if all details are correct and only then save the card. During this process, you will also be able to carry out additional checks, such as 3D Secure. If it is not possible to process a payment you should process a “zero value” transaction or at least carry out a LUHN check, or make sure your service provider does so.
LUHN check: to reduce the incorrect entry of credit card numbers in systems where validation may not occur, PANs are subject to the Luhn check algorithm. A mathematical equation that verifies the sum of its figures against the final value/digit of the card number. Information on how the Luhn check algorithm determines this number can be found here: http://en.wikipedia.org/wiki/Luhn_algorithm.
Customer Record
In the customer record, you need to save the following additional data (note that some service providers might require other data to be stored as well):
1. Expiry Date. This does not have to be encrypted.
2. A reference, often called a token. This is the string that you will use to get access to the Card Number, but can be displayed.
We would recommend that you create a token that includes the customer number (provided it is unique) and first 6 and last 4. This makes it easily searchable and can be of help when dealing with a customer on the phone.
Of course, it is different if you do not store the card data yourself. Service providers mostly provide you with a token of their own creation, which is often meaningless. You should still however ensure that your service provider gives you back the useful information as per above (expiry date, first 6 and last 4 digits). In this instance, you will need a third field in your record to store the latter.
Note: if you allow customers to stored multiple cards, you will obviously need to store this data for each of the cards separately and have some sort of index.
One-click payment
This will require you to provide your customers with a safe and secure account into which they can log in online. Within the account, the customer will as normal create a shopping cart of some form. Before the “Buy Now” button (or similar) you should give the customer the option to go to your normal payment page OR pay with a stored card. If the customer opts for this, you can skip the payment page as you can simply use the token saved in the customer record to “collect” the Card Holder data, either stored in your own database or with your service provider.
As you cannot store CVV data, you might opt to ask the customer to fill in the CVV in a separate field, which you then of course have to send in with the payment information. (Check if your provider supports this and ensure the data is not kept).
We would recommend a number of things (note: some providers will offer some of these services in addition to keeping the tokens so you might not need to build it yourself)
1. As you should keep the expiry date, you should build a logic that will disable the one-click-payment option and display a message to the client that they should update their Card Holder Data first (see below).
2. You should display the first 6 and last 4 OR last 4 digits of the card with the option to use a stored card, as this means the customer will know what card is being used. If you allow multiple cards to be used, you should display each separately.
3. You should also display a option to change or add a card if they want to use another card.
If the customer needs to edit, change or add Card Holder Data, you should bring the customer to a new screen where you would again show the first 6 and last 4 OR last 4 digits, and the expiry date of each card held. It should be possible for the customer to delete a card, add a card (which means saving a card without a purchase), or editing the expiry date (most providers offer an API to send the token with a new expiry date). Once finished you should ensure there is a button that returns the customer to the purchase, and that closing the window will do the same. The information here will of course have to be refreshed to ensure the new data is displayed.
You might want to ask a customer to go through the 3Dsecure process. Again, if using a service provider for your tokens, you should check if your provider supports the combination of a token and 3DS. As this takes away the convenience of one-click payments, we feel however you should only do so if you have a very good reason to do so. For example, if the customer just added a new card or if the goods or services purchased are of great value.
Recurring Payments
Often all payments done with a token are referred to as “recurring payments”. This is not correct. Only payments that are done on a regular, fixed interval (weekly, monthly, etc.) are recurring payments. Some acquirers also mandate that the amount should be the same.
You should talk to your acquirer, as some acquirers often specific MIDs (accounts) for recurring payments. These often offer lower rates. However, some require specific information to be added to your messaging which means additional coding. A benefit is however that such a MID does not look for a CVV code (which on a standard MID might lead to the transaction being declined).
If a recurring payment is set up as part of a purchase process, you will again simply process the payment and save the card used. This will also allow you to process the CVV and if you wish bring the customer through a 3DS check.
If however the recurring payment is set up as part of a registration process, you should provide your customers with a safe and secure account into which they can log in online. When it comes to setting up the payment information, you could use the same screen as mentioned above for deleting, editing, and adding Card Holder Data. And remember the LUHN check!
When it comes to payment, you now do not require customer involvement. You can simply “stream” payment requests into your payment service provider, using the tokens to “collect” the cardholder data, either internally or with the provider. This does however require a scheduler and a corresponding interface to set up schedules and amount. Many service providers will offer these, but they do not always offer the type of schedule that you require, so you should do some detailed checks!
Schedules should always have a start date, an interval, and an end date. Intervals can be weekly, monthly, but also a particular day in the month, a first or last day (e.g. Friday) in the month, etc. It can get tricky if you have to maintain different schedules for different customer groups.
It would also be advisable that you have some reference in the payment record in your system that shows that that payment was done as part of a particular batch, for reporting reasons.
It would also be advisable to have a retry mechanism. I.e. failed* transactions should be resubmitted for payment after x days and again after y days (if the first retry was also unsuccessful). This does of course require you to keep a reference in your system that tracks the number of times a particular payment has been tried. You should NEVER try more than three times in total. Once tried three times, you could consider sending an automatic email to the customer advising them of the failure to pay and advising them to make payment manually. This could of course also be used as an alternative to a retry mechanism, where the email would have to be sent after the first failure.
*Note: you should not retry ALL failed transactions. Depending on the failure message, some will never be successful and should not be retried. Depending on your service provider and acquirer, this information can be very generic or very granular.
Expiring cards
I would recommend that you set up a logic that will automatically warn the customer that their expiry date is coming up and invite them to log in to their account and update their Card Data.
If Cards are expired, you should have the ability to run a report containing all expired cards and the relevant customer data, so that they can be contacted manually.