How Do I Charge A Customer’s Card After The First Payment?
This is a question that we get asked a lot. After taking a card payment our existing and prospective clients would like to charge the customer again. But how can they do this in the future without making contact?
These are known as Card-on-file transactions. The process of collecting and storing payment credentials for future use. For remote commerce ecosystems this is a fundamental requirement. Although very convenient, there are significant challenges as Cardholder Not Present (CNP) fraud continues to surge.
We look at what needs attention when considering card-on-file transactions. Such as is it illegal to keep credit card details on file? What is the supporting technology? How to store card data compliantly.
Card payments are without doubt the payment method of choice for UK consumers. Debit cards alone account for more transactions than any other method. Organisations are looking for flexibility and efficiency, and card-on-file transactions are a simple way to take payments quickly.
Can I Store Card Data For Future Use?
Looking at this from a merchant compliance perspective, the practical answer is no.
Any business processing card transactions must comply with PCI DSS (Payment Card Industry’s Data Security Standard). The PCI DSS specifically prohibits the storage of Sensitive Authentication Data. This includes a PIN number or the Security Code (CVC, CVV).
Encryption is required to store the long card number (PAN). If yo do this, you open yourself to a host of security protocols. And what’s more, you don’t need to.
Card Tokenisation is a feature offered by most payment gateways. The idea is that you present, or the customer presents, their payment card information. Then the payment gateway returns a token linked to the card. This token can only be used by the gateway that created it.
You can use this token, through the same gateway, in the future to charge the card details stored by the gateway. This gets around your PCI DSS concern of card information storage.
Is It Legal To Charge A Card-On-File?
There are two laws to consider here:
1) The Data Protection Act which encompasses the General Data Protection Regulation (GDPR). This covers the storing of your customer’s personal information; and
2) The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013. Which set out how retailers should act in setting up a Continuous Payment Authority (CPA) and act during the course of a CPA.
Data Protection Act and GDPR
For the DPA and GDPR, you must have evidence that you have informed the customer of storing personal information. You need to provide the purpose and for how long you intend to keep it for. All the time you must ensure the information is deleted when no longer needed.
Continuous Payment Authority (CPA)
A Continuous Payment Authority is the industry term for a consumer using their credit or debit card to make future payments for goods or services. They can use a CPA:
- for a one-off amount to be paid in the future, for example if they have taken out a loan;
- for a regular payment, usually a fixed amount, such as a monthly subscription for online streaming services. Sometimes called a recurring transaction or instalment payment;
- for a less frequent but also regular payment, such as an annual renewal of car insurance.
In short, a CPA gives you a mandate to take payments from the customer’s account on dates of their choosing, and for different amounts, without seeking authorisation from you again.
When a customer sets up a CPA, they enter into a contract with you. You must make this clear to the customer and they must explicitly agree to it. You cannot assume they agree through the use of opt-out provisions or by a default pre-ticked box.
Let’s Look At An Example
This could be if you offer them a free trial after which payments will be taken. They should be clearly asked to agree to any future payments before money is taken. If this has not happened the contract could be considered unenforceable and they could be entitled to a refund. You must make clear the following details about the CPA:the main features of the goods, services or digital content;
- the total price (or how this will be calculated);
- all delivery charges or any other costs (or state that they are payable)
- the monthly, or billing period, costs of open-ended contracts or subscriptions
- whether the contract is of a fixed duration. Or, if it is to be extended automatically, the conditions under which it can be terminated
- the minimum duration under the contract.
Once your customer has agreed to the CPA, you should send details to them. This should include the contract and the future payments to be taken from their card.
You can make changes to the CPA during the term, although this must be done with the customer’s clear consent. If a CPA is being renewed for an additional fixed period this should be treated as setting up a new CPA and the process above should apply.
Customers’ are entitled to cancel a CPA without being charged. If you have cancellation charges when the customer cancels a product or services contract with you, these stand and must be obtained in another way other than using CPA. Any payments taken after the CPA has been cancelled are considered to be unauthorised transactions.
Continuous Payment Technology
So, you have the DPA covered and you have a Continuous Payment Authority from the customer that you can evidence. Great. Now you need the technology to tokenise the card information. By doing this, you keep out of scope of the PCI DSS. You also need an application that allows you to use the token to charge the card.
Fortunately, technology to assist you in charging a card-on-file exists in many payment gateways. Unfortunately they are often, not user friendly, require training, and have an unintuitive interface. The difficulty of this whole process is almost as difficult as ringing up the customer and processing a card payment over the phone.
PayGuard® is an example of a technology built in the present era of computer applications that don’t come with a manual. Where consideration of the User Experience is front and centre in the development process. Allowing recurring card payments, or using a token to process a payment is incredibly simple.
Some diligence is required here as you investigate the right tool for you. Looking past the marketing blurb of features and get a demonstration to see exactly how to do what you want to do. This way you can see for yourself what will work in your case.
When considering scheduled payments, future payments, recurring payments and card-on-file payments, as with many things these days technology has evolved to make the effort, and your compliance, simple enough to allow your business operation to run smoothly.
Call recording, added paragraphs to standard contracts and the use of leading fintec applications like PayGuard® can bring to life your designs. Allowing for an efficient payment process that your customers will appreciate. Plus it will keep both them and you secure and compliant.
Don’t be put off by the complexity, as your competitors are likely embracing modern financial technology to improve their processes and security. While the constant demand to drive new ways of doing things can be exhausting, when you work with trusted partners like us, you can lean on them for advice and focus on what really matters to you.