What is the Second Payment Services Directive (PSD2)?
The Second Payment Services Directive is an EU Directive designed to regulate payment services and payment service providers throughout the European Union and European Economic Area. It is generally accepted that this regulation will be enforced in the UK‚ regardless of the outcome of Brexit.
The aim of PSD2 is to create a safer and more secure framework for online payments‚ alongside promoting the development of innovative online/mobile payments through open banking standards.
This has created a requirement for the biggest nine UK banks to release APIs (Application programming interfaces) that will enable third-party providers – known as AISPs (Account Information Service Providers) and PISPs (Payment Initiation Service Providers) – to access bank accounts and create an entirely new‚ independent services. This is an exciting development for FinTech providers and start-ups‚ as the payments ecosystem will be opened up to new entrants.
Another important element of PSD2 is the requirement for Strong Customer Authentication on the majority of electronic payments.
Important note: PSD2 comes into full effect on 14 September‚ 2019.
Update: On the 13/08/19 The Financial Conduct Authority (FCA) agreed a plan that gives the payments and e-commerce industry extra time to implement Strong Customer Authentication (SCA).
Strong Customer Authentication Explained
Strong Customer Authentication (SCA) is a new European regulatory requirement to reduce fraud and make online payments more secure.
Strong Customer Authentication will apply to “customer-initiated” online payments within Europe. As a result‚ most card payments and all bank transfers will require SCA.
Important note: This is applicable to transactions in the European Economic Area (EEA) only‚ where both payer and payee are in the region.
To accept payments once SCA goes into effect‚ online retailers will need to build additional authentication into any online payment flow.
There are however some exemptions that will not require SCA:
- Recurring Direct Debits are considered “merchant-initiated” and therefore do not require SCA
- Online payments of less than €30‚ to a maximum cumulative value of €100 or five transactions‚ will be exempt
- Transaction risk analysis based: a transaction can be exempted from SCA if it is “low risk”.
- This will only be allowed if the payment provider’s / bank’s fraud rate does not exceed the following:
- 0.13% to exempt transactions below €100
- 0.06% to exempt transactions below €250
- 0.01% to exempt transactions below €500
- Corporate payments: this includes ‘secure virtual payments’‚ such as virtual cards or B2B cards initiated by a “legal entity”. (e.g. a business).
- Whitelisted merchants: consumers can whitelist merchants so that all future transactions with that merchant do not require additional security checks.
- Recurring payments: this refers to recurring card payments made to the same merchant for the same amount.
- Phone payments will be exempt
- Payments made with saved cards when the customer is not present (“off-session”) may qualify as merchant-initiated transactions.
- To use merchant-initiated transactions the following needs to occur:
- Authenticate the card either when it’s being saved or on the first payment.
- Get an agreement from the customer (also referred to as a “mandate”)‚ in order to charge their card at a later point.
Potential Business Impact of SCA
- Banks will decline payments that fail to pass SCA when required
- Applications that use one-off payments or subscriptions will be required to facilitate SCA should the payment exemption be rejected by a bank
- Poor authentication UX may lead to high customer drop off. Consideration of user flow and user experience must form the core of any SCA solutions.
- Exemptions are key to improve conversion – these are difficult to manage though. It is worth using a payment gateway‚ such as Stripe‚ to manage and optimise this for you.
- We ultimately predict that these changes will result in further bank logic evolutions and increased complexity in processing online payments.
How to implement SCA
Strong Customer Authentication Methods
SCA requires authentication to use at least two of the following three elements.
- Knowledge (something only the user knows‚ e.g. a password)
- Possession (something only the user possesses‚ e.g. a device)
- Inherence (something the user is‚ e.g. biometrics)
Currently‚ the most common way of authenticating an online card payment relies on 3D Secure 1‚ a process you may have experienced after checkout.
3D Secure 1 ensures users are prompted by their bank to provide additional information to verify the purchase. This introduces user friction‚ as the user is often prompted to create a static password which can be hard to remember.
Under 3D Secure 1‚ authentication is required on an exception basis. In practice this means where the transaction is considered high risk‚ additional authentication may be triggered via 3D Secure. This is known as a “step-up”.
After September 2019‚ additional authentication will become the default. All qualifying transactions will be required to be “stepped up” unless one of the exemptions listed above applies.
3D Secure 2 is an evolution of 3D Secure 1 and is set to be the main method for authenticating online card payments and meeting the new SCA requirements.
3D Secure 2
3D Secure 2 (3DS2) adds “frictionless authentication” and improves the purchase experience compared to 3D Secure 1. It also allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank.
This includes payment-specific data like the shipping address‚ as well as contextual data‚ such as the customer’s device ID or previous transaction history.
The cardholder’s bank can use this information to assess the risk level of the transaction and select whether to approve or deny the payment.
How hedgehog lab is implementing SCA
We integrate the majority of our mobile and web platforms with Stripe‚ a suite of leading payment APIs that is used by millions of companies in over 120 countries.
We know that a key concern for clients is to reduce any user friction or chrun. To ease both of these we are taking the following measures.
One-off payments
Stripe’s API allows us to authenticate a card when it’s being saved for later use and mark subsequent payments as “merchant-initiated transactions.”
Subscription Payments
Laravel Cashier is a wrapper around the Stripe API that we use to process recurring subscription revenue.
Cashier has received an update in the latest version (10) to provide SCA. (However it is worth noting that legacy applications may need a full Laravel upgrade in order to make use of Cashier 10.)
Transaction Risk Analysis
This is the preferable implementation of SCA and is recommended by Stripe‚ who will automatically send a request for exemption to the bank for low risk transactions.
FAQs:
My transactions fall under the exemptions, do I still need to implement SCA?
Yes. Absolutely.
As the bank controls whether the exemption applies and the bank is not obliged to conform to the exemptions list‚ it is recommended that all payment gateways are SCA compliant.
Will existing subscriptions be required to undergo SCA?
Only new subscription transactions on platforms will be required to undergo SCA. If there is a historical transaction which has been authenticated (e.g. a current card that has previously been used)‚ this will not need re-authentication under SCA.
However if an existing user adds a new card it’s likely that they will be required to undergo SCA.
