To begin with, the PSD2 refers to the Payment Services Directive 2, which enables secure electronic payments through strong account holder authentication for electronic transactions. It applies to the 28 countries of the European Economic Area and concerns all merchants who process their card payments via European purchasers.

The initial effective date as communicated by the EBA (European Banking Authority) was on September 14, 2019.

In agreement with the local banking authorities, the effective date for the PSD2 has been postponed from 12 to 18 months depending on the country, to allow all stakeholders in the ecosystem to be ready.

A reminder of what Strong Customer Authentication is:

Intended to reinforce the security of electronic payments, the purpose of Strong Authentication is to verify the cardholder's identity. For this, at least two of the three following three authentication factors must be validated:

• An element known by the cardholder: password, PIN number, secret question, etc.
• An element possessed by the cardholder: mobile phone, smartwatch, etc.
• An element inherent to the cardholder: facial recognition, voice recognition, digital fingerprint, etc.

The independence of these elements is guaranteed in the event of a compromise of one of the factors, the integrity of the second.

RTS:

A review of Regulatory Technical Standards RTS refers to the set of technical standards that define the requirements of the PSD2.

3D Secure:

• 3D Secure V1: Developed by Visa, Mastercard and American Express, 3D Secure (or 3DS) is an authentication system whose goal is to improve the security of online purchases. 3D Secure adds an additional level of security by asking the purchaser to enter a password before finalizing the online transaction. This system is common in Europe and is now used by thousands of e-merchants to combat fraud.

  
• 3D Secure V2: 3D Secure V2 is the latest version of the 3D Secure protocol. It offers a new approach to the authentication process for online transactions, and complies with the authentication rules required by the PSD2. Unlike V1, this new version will allow merchants the ability to offer their end customers a smoother purchase experience with no redirection and with fewer friction points. It provides enhanced protection against fraudulent transactions through a risk analysis of transactions based on more than 150 contextual pieces of data collected at the time of purchase.

With 3D Secure V2, authentication of the end customer will take place directly via the payment page, and will be entirely compatible with mobile/desktop web environments in addition to in-app purchasing. Version 2 will keep the end customer on the payment page, unlike the previous version which required a redirection to a page made available by the issuer.

3D Secure V2 will apply to all electronic payments such as online payments, mobile payments, in-app payments, or those made via connected objects.

Transfer of liability (liability shift):

This refers to the transfer of responsibility to the cardholder's bank (the issuer). As a merchant, if a transaction has been strongly authenticated but is subsequently disputed on the basis of fraud, you will not bear the cost (chargeback).

Exemptions allowed by the PSD2:

The exemptions apply to transactions which may be subject to a strong authentication exemption as provided for in the PSD2.

A merchant may request the application of an exemption from the issuer (in this case, no transfer of liability is applied if the exemption is accepted by the issuer), but issuers may also apply an exemption (with transfer of liability) on their own initiative.

These are the exemptions allowed by the PSD2:

• Low-risk transactions less than €30, except when the cumulative amount of the card carrier's purchase since the last strong authentication is more than €100 or if five consecutive transactions have already been exempted.
• Low-risk transactions (Transaction Risk Analysis - TRA)
• Recurring transactions of the same amount and due date to the same recipient. However, strong authorization of the end customer will be required as part of the first transaction or during the configuration of a series of transactions (provided that it's initiated by the end customer).
• Subsequent transactions will be electronically linked, in order to trace them back to the first strongly authenticated transaction.
• Merchants reported as trusted recipients to issuers: An end customer can declare a merchant as a trusted recipient to his or her bank. Once registration has been completed and validated, all future transactions made on that site will be exempt from strong authentication.

• Transactions initiated by the merchant: All transactions or series of transactions of an amount and/or a fixed or variable frequency, the total amount of which is not known at the time of initiation, are considered to be outside the scope of the PSD2. Examples of transactions initiated by the merchant: subscriptions, no-shows (applicable to the goods and services rental sector) and installment payments.
• MOTO (Mail Order, Telephone Order) Transactions: Orders by mail, telephone or other means that do not directly involve the end customer in initiating the transaction are outside the scope of PSD2.
• Inter-regional transactions (OLO: One Leg Out): Any transaction whose issuer or purchaser is located outside the European Economic Area is considered outside the scope of the PSD2.

Contextual data:

Also known as transactional data, this data is collected during the purchasing process jointly by merchants and by HiPay. It is then sent to the issuer. The issuer uses this data to perform a risk analysis and to decide on the status to attribute to the transaction.

If the transaction is low risk and falls within the scope of exemptions provided by the PSD2, strong authentication will then not be required and the purchase process will be frictionless for the end user.

Conversely, if the transaction presents a risk, the end user will be required to undergo strong authentication.

In either of these cases, the transfer of liability to the issuer shall apply unless the merchant is the source of the exemption request.

Soft Decline:

Soft declines are rejections of authorization due to non-authentication of the transaction. Under the PSD2, all transactions must go through an authentication process and cannot be sent directly for authorization (unless the transaction does not fall within the scope of the PSD2).       

In case of non-compliance, issuers shall decline the transaction in the form of a new authorization return code called "soft decline" (to differentiate it from a hard decline).

You're not compliant yet with the PSD2? Get the help of an expert to deploy it.