What is PSD2?
With the Regulatory Technical Standards (RTS) arising from the second Payment Services Directive (PSD2) coming into force on 14 September 2019, applicable to the entire European Economic Area, new requirements in terms of strong authentication must be applied to all transactions carried out over the internet.
These new authentication requirements will have an impact on users’ customer journey. However, the PSD2 above all seeks to reduce fraud for online payments, by providing more security, both for users and for merchants. With democratization of online commerce, a sector that has seen ever-stronger growth each year, it became essential to increase end users’ trust when they buy online.
This is the goal of the PSD2: to strengthen and increase e-shoppers’ trust
The move to systematic strong authentication, the responsibility of issuers
Today, merchants choose to apply or not apply strong authentication for their customers. In fact, they themselves or their payment service provider decide to use strong authentication for transactions based on their fraud management policy, by activating 3-D Secure 1.0. Then end customers are directed to a page from their bank, where they must enter a one-time code to prove their identity, generally received by SMS.
When it is used, this system protects consumers from fraud and grants the liability shift, by transferring responsibility to the end customer’s bank (also called “cardholder’s bank” or “issuer”). However, using 3-D Secure 1.0 generally impacts user experience (poor compatibility with mobile environments and applications, not receiving the SMS code, etc.) decreasing the merchants’ rate of converting them to customers.
With PSD2, the rules changed: the final decision to use (or not use) strong authentication is no longer the merchant’s choice, but rather the issuer’s, no matter the merchant’s initial request.
This decision will be made based on the number of criteria defined in the new regulation and according to the issuer’s ability to clearly identify the end customer. To facilitate this identification, the issuer will carry out risk analysis based on the contextual data of the purchase collected jointly by the merchants and by HiPay.
Hence, there are over 150 types of data collected during the purchasing process that will be sent and from which issuers may carry out this risk analysis, and decide to allow the transaction.
When the issuers deem that the data sent identifies the cardholder, or that the transaction meets certain eligibility requirements, the authentication process will be completely transparent for the end user, and therefore, without friction. Conversely, when the data will not allow the cardholder to be identified, the latter will be requested to carry out strong authentication.
Strong authentication (“Strong Customer Authentication” or SCA) must apply at least two independent authentication factors from among the following three:
Something known by the end customer: password, secret question, etc.
Something owned by the end customer: smart phone, badge, chip card, token
Something inherent to the end customer: fingerprint, facial or vocal recognition, iris recognition
New details of the 3-D Secure 2.0 protocol
In addition to including new data within the 3-D Secure 2.0 protocol, this new version of the protocol allows for offering a better integrated customer journey within different purchasing environments (web, mobile, applications), without redirection, and reducing the friction points for the end user. Additionally, the major innovation of the protocol is the integration of innovative authentication methods, for example, vocal or facial recognition, or a digital fingerprint.
3-D Secure 2.0 applies to all electronic payments, which means web, mobile, and in-app payments or those carried out through connected devices.
Transactions outside of the scope of PSD2 and exempt from strong authentication
Certain transactions may be exempt from strong authentication, or are simply outside of the scope of PSD2.
Using the anti-fraud tools of HiPay, our teams will work together with merchants to allow implementing optimal exemptions, with the goal of maximising the fluidity of the customer journey, while actively fighting fraud.
Transactions outside of the scope of PSD2:
The liability shift of the transactions that are outsiding of the scope of PSD2 only applies on the issuers if the merchant decides to strongly authenticate the final user (as previously with the 3-D Secure 1).
→ Transactions initiated by the merchant: All transactions or series of transactions of a fixed or variable amount and/or frequency that have been subject to a prior agreement between the end customer and the merchant, allowing the latter to carry out payment without the cardholder’s involvement, are considered outside the scope of PSD2. Thus, these transactions are not subject to strong authentication.
Examples of transactions initiated by the merchant: subscriptions, no-show (applicable to the sector of renting goods and services), payments divided into multiple instalments
→ MOTO transactions (Mail Order, Telephone Order) : Orders by correspondence, via telephone or through other means not directly involving the end customer in the transaction, these are outside of the scope of PSD2.
Nota Bene : The transactions realized via Interactive Voice Response are considered like electronic transactions and answer to the same PSD2 authentication requirements.
→ Inter-regional transactions (OLO : One Leg Out) : Any transactions in which the issuer or acquirer are located outside of the European Economic Area are not subject to strong authentication.
Transactions exempt from strong authentication
The merchants can ask an exemption to the issuers for the transactions described below. even if the exemption is allowed by the issuer, the merchant will be responsible in case of fraud.
So there is no liability shift to the issuer. But the issuer can decide to not apply the exemption that the merchant asked for.
→ Low-risk transactions less than 30 € : Transactions of an amount less than €30, of a daily cumulative amount of less than €100 or for a maximum of 5 successive transactions are exempt from strong authentication (the sixth transaction must be strongly authenticated).
→ Transaction Risk Analysis (TRA) : Transactions with a low level of risk and for predetermined amount thresholds may be exempt from strong authentication based on the fraud level of acquirers and issuers.
|Amount||Reference Fraud level|
|30 - 100€||0,13%|
|100 - 250€||0,06%|
|250 - 500€||0,01%|
*This reference fraud level will be communicated by the PSP from the 1rst of January 2020
→ Recurring Transactions : Recurring transactions of the same amount and from the same payee are exempt from strong authentication However, strong authentication of the end customer must be applied for the first transaction, or during configuration of the series of transactions (on the condition that it is initiated by the end customer).
The following transactions will be technically linked, in order to connect the following transactions to the first one which got strong authentication.
→ Merchants declared as trusted beneficiaries to issuers: End customers may declare their preferred merchant sites as a trusted beneficiaries to their bank. The merchant or the payment service provider cannot be involved in this agreement between the consumer and their bank. Once registration has been carried out and validated, all future transactions made on this site will be exempt from strong authentication. However, strong authentication must be carried out during registration.
The technical rules of this exemption are not defined yet. The issuers haven’t set implementation deadlines.
→ Transactions made through anonymous payment methods: Anonymous payment methods such as prepaid cards are exempt from strong authentication.
What support is there to easily be in compliance?
Implementing the new protocol does not modify the current architecture between the merchant and HiPay. However, in order to maximise the success of your transactions and simplify your customers’ journey, it is strongly recommended to integrate the new PSD2 fields to provide to HiPay.
Example of necessary information
Previous authentication information
- Authentication method of the last transaction
- Date and time of authentication of the last transaction
- Reference of the last authentication
Browser agent information
- Java enabled
- Customer’s IP address
- Screen size
- Date the customer opened his account
- Date of last password change
- Date of last change to customer profile
- SDK Interface
- UI Type
- App ID
HiPay supports all merchants in putting in place exemptions and in the proper use of an intelligent system to fight fraud.
This support will allow HiPay to carry on its mission: helping merchants to maximise their success while actively fighting fraud attempts.
We invite you to check our Support Center to learn about the new fields to integrate or for more technical details.