PSD stands for Payment Services Directive. Unlike most regulations that people in the card payment industry are familiar with, these are not scheme rules (rules created by Visa, MasterCard, AMEX, etc.), but European legislation. This is why merchants cannot negotiate their way out of compliance, as sometimes is possible with scheme rules. This is a law.
PSD1
The ‘2’ means this is the second such law. The first one was implemented in 2007. It provided the legal foundation for an EU single market for payments, to establish safer and more innovative payment services across the EU. The objective was to make cross-border payments as easy, efficient, and secure as ‘national’ payments within a Member State.
One stipulation was that any payment method would have to be available across the union. The end of purely national payment schemes, such as Laser in Ireland, was a result of this. Other ‘national’ payment schemes survived by going co-branded. Essentially this meant that they would keep their brand, but use the infrastructure of Visa or MasterCard to process payments.
Also part of the legislation was a cap on pricing. This was done by limiting the ‘interchange’ fees for consumer cards to 0.3% for credit cards and 0.2% for debit cards. You can read more about the costs of card payments elsewhere on this site.
PSD2 is about more than making payments safer
As mentioned PSD2 is the second European law dealing with payments. Like the first one, it is a very comprehensive set of laws, and the main aim is the loosen the stranglehold that Visa and MasterCard have on the card payments market. It introduces concepts such as Payment Initiation Services and Account Information Services. In both cases, banks are compelled to open their systems and share their data with third parties, who, it is hoped, will start offering competing services to card payments, especially bank-to-bank transfers.
There is also increased consumer protection in the legislation. One component of this, but by no means the only one, is SCA. Strong Customer Authentication means that any payment needs to be accompanied by proof it is the owner of the card who is making the payment and not someone who just happened to get hold of the card number.
This burden of proof is quite strict; it requires two separate pieces of information to be submitted. And the card number itself is not one of them!
The information allowed as proof falls into three categories:
- Something only the cardholder knows, such as a PIN or password.
- Something only the cardholder has, such as a phone or token.
- Something the cardholder is, such as a thumb print.
So, what does this mean in practice?
There are quite a few scenarios, which I will go through one by one.
The customer is physically present.
To keep things simple, you should only accept two types of payment:
- Contactless payments
- Payments confirmed by Chip and Pin
Any other process, such as swiping a card or entering the card number manually, could lead to the payment being declined. I am saying ‘could’ because, in the end, the bank that issued the card to the cardholder has the final say. But to be safe, you should limit yourself to contactless and Chip and Pin.
The Issuer has final say
Within the bounds of the law, it is the issuers who decide to accept or decline any payment. They are completely free to make their own decision, and neither the cardholder, the merchant, the merchant’s bank, or even the scheme has any say in this. And they don’t even have to tell you why. As a matter of fact, the algorithms they use would be considered commercially sensitive. Hence the fact that most transactions that are declined get the “05” decline code: a generic decline.
Contactless payments are for low values only. In most countries, this means up to €50. You should be aware though that if someone has used their card for 5 subsequent contactless payments, or for subsequent payments for a total value exceeding €150 the law mandates that the payment is secured by Chip and Pin. If your terminal is set up for it, it will ask for the card the be inserted and a PIN entered. If it isn’t, it will decline the transaction. You should in this case advise the customer to retry with Chip and Pin. Once a card has been used for a payment using Chip and Pin it will ‘reset’ and it can again be used for up to 5 contactless payments/a cumulative number of contactless payments not exceeding €150.
A Chip and Pin payment is for all other payments, only limited by the amount allowed or available on the card. This is the safest form of payment, as any claim by the cardholder that it was not them who made the payment will be rejected.
The myth of a guaranteed payment
A Chip and Pin transaction will protect a merchant against a claim of a cardholder that it was not them who made the payment. But a cardholder might still contest a payment (chargeback) on the basis that the service was not provided/did not meet expectations, etc.
This is a simplified overview, and there are exceptions, but in principle, you should not take a payment by swiping a card or manually entering the card number if the customer is physically present. Only use the two accepted methods described above.
The customer is on the phone.
In this case it acceptable to enter the card number in your terminal or booking system to take a payment. What you have to ensure though is that the transaction is correctly processed as a MOTO transaction. MOTO stands for Mail Order/Telephone Order. The former hardly exists anymore, but the second one is still very popular.
The following differs from terminal to terminal, but when manually entering a transaction in your terminal, the first option is almost always to select the type of transaction. This is where you have to choose MOTO. When staff is rushed, they often choose the first option, typically a standard sale. This will lead to this transaction being flagged as a PKE, or Pan Key Entry. On average a quarter of these get declined, and this rate is rising. And you might be liable to fines from your processor. You should therefore choose the MOTO option.
If you are using a booking system instead of a physical terminal, you should contact the provider of this system to ensure they flag transactions correctly.
Choose the correct transaction type for telephone orders
You should contact your terminal provider to get instructions on how to choose the MOTO transaction type and train your staff on how to do this.
And talk to your booking system provider.
The customer is making a payment on your website.
As with payments where the customer is physically present, there is a separate process for low-value and high-value transactions. However, to keep things simple, I advise you to always use 3D Secure. This is basically the equivalent of the PIN for transactions when the customer is present.
3D Secure and losing sales
Initially 3D Secure meant the customer had to know their password. Often they did not and would abandon your shopping cart. Nowadays, however, in most cases, the cardholder gets sent a code to their mobile. This had led to much-improved acceptance levels.
It is important to make a distinction between authentication and authorisation. The former means the customer successfully proves it is them who is giving approval to the payment. The latter is the decision of the cardholder’s bank to approve the transaction.
If you process a transaction using 3D Secure the following might happen (this is again a simplified overview):
- The 3D Secure process (authentication) fails. Although in some small number of cases this might be caused by a technical issue, in the majority of cases it is because the cardholder did not put in the correct password/PIN. You should never proceed with such a transaction.
- The authentication is successful, but the transaction is declined. As per above, this is because the issuer decides not to accept it. This might be because there are not sufficient funds on the card, but it could be any other reason.
- The transaction is accepted. And because of 3D Secure, the merchant is protected against disputes if the stated reason is that the cardholder claims it was not them who agreed to the transaction. As per above though, there might be other reasons though that 3D Secure does not protect against.
Some notes on 3D Secure:
Sometimes the issuer might decide to accept the transaction without invoking 3D Secure, especially when the transaction value is low. In industry jargon, this is described as “Attempt Acknowledged”. The merchant is protected against disputes if the stated reason is that the cardholder claims it was not them who agreed to the transaction. As per above though, there might be other reasons.
There are different versions of 3D Secure. The original system is now called version 1. To complicate things, there is no version 2. Instead, there is a version 2.1 and a version 2.2. Version 1 is still the most popular and is still being accepted. But it is being phased out, with both Visa and MasterCard announcing that support for the system will end in October 2022. If you have not yet moved, start planning to do so. Your Gateway will be able to advise but be aware that some development work will be required.
Merchent Initiated Transactions (MIT)
All of the transactions mentioned above have one thing in common: the cardholder is there (physically, on the phone, or in front of their computer) to give his or her consent to the payment. Therefore these are called Cardholder Initiated Transactions. The other main category is Merchant Initiated Transactions (MIT). As the term indicates, these are transactions where the merchant is processing a transaction, without the cardholder being around in any shape or form. An example of this is a hotel processing an additional bar charge after the customer has already departed. They can also be system generated, for example for a utility bill or subscription.
Often it is thought that every transaction using a saved card (mostly referred to as a ‘token’, but officially a ‘Credit on File’) is a Merchant Initiated Transaction. This is however not the case for so-called “one-click” transactions.
Credit on File (COF) transactions
Credit On File (COF) is just a fancy way of saying you have saved the card details of your customer in your system.
Transactions, where a customer places an order on a website and decides to use a previously processed card (the COF), are Customer Initiated Transactions, as the customer is at their computer, assenting to the transaction. This means they will have to be processed using 3D Secure.
How to deal with real Merchant Initiated Transactions is quite complex if you want to do it correctly. I will explain below what I believe the best approach is.
In the vast majority of cases, this process is online, so this is what I will focus on. You will have to speak to your e-commerce gateway and booking system/accounting system provider to implement this.
Getting Customer Agreement
You MUST have an agreement from your customer to save their card details, for what type of charges you can use them for, and for how long you are going to keep their details. You must specify these in your Terms & Conditions, and get confirmation from the cardholder that he or she has accepted these (ticking the box).
T&C’s and Chargebacks
Schemes will look for proof of agreement by the cardholder for the payment according to their rules. These take precedence over your Terms & Conditions and as such referring to these will not automatically win you chargebacks. But they are taken into consideration, for example for no-show transactions. You will have to prove the customer’s acceptance of YOUR Terms & Conditions though. Acceptance of those of an intermediary such as booking.com is not acceptable.
Customer Authentication
If you are taking a payment, and as part of that process (offer to) save the customer’s card details, you should already be doing this, as per the web order process above.
If you are not taking a payment, for example if you are taking only a booking, you will still need to do a customer authentication. You can do this by processing a “zero value” transaction. This process works exactly the same for a normal transaction, and the cardholder will have to go through the 3D Secure process. Because the value is zero, there will obviously no reservation on the customer’s card and no funds will move.
The Reference Number
In both the above scenarios, the authorisation needs to be slightly different, in that it needs to tell the acquirer, card scheme, and issuer that you are saving card details for future use for a MIT. The issuer will respond by providing you with a reference number, which you will need to save (which is where your booking or accounting system provider comes in).
You are now set up.
Raising a MIT payment
You can only raise a payment for the reasons outlined and for the period agreed in the Terms & Conditions. The payment needs to be raised via your booking or accounting system. Terminals do not support raising MITs. The transaction again is slightly different in that it needs to contain the reference number and tell the acquirer, card scheme, and issuer that this is a MIT. Your ecommerce gateway should support this.
Examples of MIT are: subscription payments, no show payments in hospitality, payments following express checkouts, delayed delivery payments, payment for damage/fines/tolls in car rental, etc.
Summary of Transactions
Chip and PIN transaction
Chip and PIN (EMV in industry-speak) will give you liability shift for claims of fraud and are seen as the most secure.
Swiped transaction
Payment is made via “swiping” the card through the card reader of the terminal. This transfers the card number and other data from the magnetic stripe on the card to the terminal.
This type of transaction is not compliant with SCA, has no liability shift, and will be more and more declined.
GooglePay, AndroidPay or ApplePay transaction
These are wallets in which the card of the customer is saved. As such these are ‘normal’ card transactions. Instead of a PIN, the customer authenticates themselves via a biometric: a fingerprint or the face. Most issuers limit the amount you can pay via these wallets, but it is expected that these will be increased over time.
Contactless transaction
But with limitations. These are*: a maximum of €30 per transaction, €150 for total subsequent transactions, and a maximum of 5 subsequent transactions regardless of value.
*Due to COVID-19, the limits have been temporarily increased.
If these are exceeded, your terminal should not decline the transaction, but ask for a Chip and PIN. There are however still many older terminals around which do not support this, and they will decline the transaction.
Contactless PIN transaction
Although not yet widespread, it is expected that more and more cards and terminals will support contactless PIN. In this case, the cardholder taps their card and enters their PIN without having to insert the card. These transactions will allow much higher transactions to be processed.
Ecommerce transactions, including Card-on-File/One-click transactions
As per above, 3D Secure is now mandatory, and as such these transactions are compliant. This is also why increasingly transactions without 3D Secure (‘Unsecure’ transactions) will be declined.
Note: transactions using 3D Secure version 1 will be supported until October 2022. After this date, they will no longer be accepted. You will have to prepare for moving to version 2.1 or 2.2 before this time.
PKE transaction
A Pan Key Entry transaction is a transaction where the merchant records the card details and processed the payment at a later stage by entering the card manually.
This is no longer compliant and these transactions will be increasingly declined. Instead, Merchant Initiated Transactions should be used.
MOTO transaction
A Mail Order/Telephone Order transaction is a transactions where the customer gives their card details over the phone. As per above, provided correctly flagged, these are compliant.
As many merchants are not ready yet for Merchant Initiated Transactions, many have switched to using MOTO for these transactions. Whilst not correct, this is currently tolerated by the schemes.
Merchant Initiated Transactions
This has been extensively discussed above. Properly implemented these transactions are compliant.
Final Notes
These rules and regulations sound and perhaps are cumbersome. But there is a good reason for them. The fastest-growing part of the payments market is e-commerce. These payments are however also the most fraud-sensitive. A customer who becomes a victim of fraud, will probably not buy online (or via a app) again. If that becomes widespread, merchants will suffer. It is therefore in everyone’s interest to make transactions as safe as possible. Because we all know that prevention is better.
