What is PSD2?
The EU Payment Service Directive 2 (PSD2) is a European Commission initiative to increase consumer security and protection for European payment processing. The PSD2 mandate requires all electronic payments within the European Economic Area (EEA) and the United Kingdom to have Strong Customer Authentication (SCA).
PSD2 is an important step towards a Digital Single Market in Europe, which aims to make the EU’s single market fit for the digital age. The new measures will also ensure that all PSPs active in the EU are subject to supervision and appropriate rules. There will be wide-reaching implications for a range of parties including banks, other PSPs, FinTechs and customers.
What is Strong Customer Authentication?
Strong Customer Authentication (SCA) is a new requirement of the second Payment Services Directive (PSD2), which aims to add extra layers of security to electronic payments.
SCA will apply to the European Economic Area (EEA) and the United Kingdom. It will require banks to perform additional checks when consumers make payments to confirm their identity. To do this, banks may ask for a combination of two forms of identification at the checkout. Examples include:
When is Strong Customer Authentication Required?
Strong Customer Authentication applies to Customer Initiated Transactions (CITs). As a result, most card payments require SCA with the exemption of Mail Order Telephone Order (MOTO). Recurring Payments such as direct debits are considered Merchant Initiated Transactions (MITs) and do not require SCA.
For online card payments, these requirements apply to transactions where both the business’s and the cardholder’s banks are in the European Economic Area (EEA) and the United Kingdom.
How do you strongly authenticate an online card transaction?
Strongly authenticating an online card payment often relies on 3-D Secure. Applying 3-D Secure adds an extra step after the checkout, where cardholders are prompted by their banks to provide additional information to complete a transaction (e.g. a one-time code sent to their mobile phone or biometric authentication through their mobile banking apps).
EMV 3-D Secure (“3-D Secure v2”) is the latest version of the authentication protocol and is used to authenticate online card transactions whilst adhering to the SCA requirements.
Payment methods such as Apple Pay and Google Pay already have an inbuilt layer of authentication that supports payment flows by using biometric readings and/or passwords that will allow businesses to offer a frictionless checkout experience whilst meeting the new requirements.
Identifying out of scope and exempt transactions
By correctly identifying out of scope transactions and applying the exemptions, Merchants can minimise friction and reserve SCA for when it is needed:
Further Information on Transaction Types
|Credential on file transactions (CoF)||
Credential on File (CoF) is the process whereby cardholders authorise Merchants to store their credentials (including but not limited to an account number or payment token), so that the same Merchant can use them again at a later date.
CoF is a requirement from Visa and Mastercard to provide greater visibility for all parties into transaction processing to identify initial storage and subsequent usage of stored credentials to determine the risk level.
If the Merchant offers the cardholder credentials storage for future or recurring use, it is required that the Merchant has cardholder consent and must follow Visa and Mastercard rules.
A stored credential can be Cardholder or Merchant initiated.
|Cardholder Initiated (CIT)||
In this type of transaction, the cardholder actively selects the card to use and completes the transaction using previously stored details.
They are limited to Sale, Pre-authorisation, and account verifications.
|Merchant Initiated (MIT)||
In this type of transaction, the Merchant submits a transaction using previously stored details without the cardholder's participation.
This type of transaction can only be processed on a previous CIT. An example of this is a recurring payment.
It is important that merchants and acquirers can identify and clearly flag transactions that match the criteria for being out of scope or exempt. When in scope, authentication must be performed and EMV 3-D Secure must be supported.
SCA based benefits for EMV 3-D Secure 2.X
SCA has various requirements to which merchants must adhere. Once merchants have completed the upgrade from 3DS Version 1 to EMV 3-D Secure, preferably at the highest version available, they will be able to leverage the SCA requirements fully and make use of the exemptions to deliver a best-in-class payment experience for the cardholder.
|3-D Secure 1.0||• Basic two-factor authentication
• Support with dynamic linking
|EMV 3-D Secure 2.1||• Support with real time dynamic linking
• Mobile device compatibility
• Reduction in fraud related transactions
• Enhanced data sharing
• Biometric authentication
• Merchant Initiated Transactions (varied implementation by schemes)
|EMV 3-D Secure 2.2||
All features of 2.1 plus:
How to recognise and respond to an SCA Soft Decline
What is a SCA soft decline?
A soft decline response code indicates that the card issuer is not willing to authorise a non SCA transaction and wants you to step up that transaction with SCA which can be achieved with 3D Secure authentication.
Merchants must be able to recognise a soft decline response and respond accordingly or they will risk an increase in failed transactions.
How do soft declines work?
What is a SCA soft decline and what should you do?
If an issuer soft declines a transaction and requires it to be re-attempted with SCA applied, you will see a Response Code of 65 in the authorisation message.
If your transaction is soft declined, then you should retry with 3-D Secure v1 as a minimum but preferably EMV 3-D Secure (3-D Secure v2). If your transaction is then successfully authenticated through 3-D Secure, please proceed to authorisation.
Merchants using the Hosted Forms will benefit from soft declines being handled automatically. Merchants using the Direct API will need to handle this scenario within their application.
Article is closed for comments.