3ds 2.0: what happens now?
For more than 15 years Ecommerce payments have been protected by 3D Secure. This protocol allows for the involved actors to authenticate the buyer in a secure way.
The ongoing technological evolution and the increase in the number of transactions has brought about the necessity of updating the authentication infrastructure in order to increase the reliability of the system while improving the buyer experience, thus increasing conversion rates.
The cooperation between the schemes, European authorities and market players resulted in the definition of a new standard for authenticating online buyers: 3D Secure 2.
The new protocol will grant continuity in accordance with upcoming legislations (Revised Payment Services Directive, better known as PSD2) and minimizes impact on merchant's systems. While doing so, the customer experience will be improved as well, being optimized for more devices.
3DS2 and Strong Customer Authentication (SCA)
EMV 3D Secure 2 is the best way to achieve compliance with PSD2 RTS.
Whereas with 3D Secure 1.0 every transaction undergoes an authentication which always requires an action from the buyer, the application of 3D Secure 2 may result in two different outcomes: challenge flow or frictionless flow.
The Revised Payment Services Directive (PSD2) introduces the obligation for European banks to authenticate the buyer for online payments within European Economic Area (EEA). When a challenge flow occurs, the issuing bank requires a Strong Customer Authentication (SCA).
A SCA consist in an authentication based on at least two of the following factors:
- Possession : something you have (eg. mobile phone, OTC token, wearable device)
- Knowledge : something you know (eg. password, PIN)
- Inherence : something you are (eg. fingerprint, facial features, behavioral pattern, voice pattern)
An example of SCA is an authentication done with a one-time-password the buyer received on his smartphone (factor 1: possession) and a static password (factor 2: knowledge).
While PSD2 requires the strong customer authentication of the buyer for remote transactions, in some cases an exemption is allowed.
When an exemption is applied, a frictionless flow occurs. The more informations are passed to the issuing bank, the more likely it is for the transaction to result in a frictionless flow.
In this scenario the authentication does not require any involvement of the buyer.
In case a card which would otherwise be in scope for PSD2 is not enabled to 3D Secure 2, the system will attempt performing a 3D Secure 1 authentication flow.
Should this attempt fail as well, the transaction will skip the authentication phase and an authorization of the transaction will be attempted.
Out of scope transactions and exemptions
For some types of transactions the application of a SCA can be avoided. These transactions may be Out Of Scope transactions, or exemptions.
Out of scope transactions are transactions which are not subject to the legislation. For these transactions the rules imposed by PSD2 do not apply.
The following types of transactions are considered out of scope:
- One Leg transactions : these are transactions for which the acquirer or the issuer are not within the EEA
- Merchant-Initiated Transactions (MIT): these are transactions initiated by the merchant in the absence of the buyer
- Mail Order or Telephone Order transaction: these are orders placed by telephone, by sending an order form in the postal mail, or by otherwise providing card data directly to the merchant in order for him to manually process the specific transaction for which card data is provided.
- Anonymous Cards: these are payment cards that can be identified only by the issuing bank
These transactions are not subject to PSD2 and may be processed without authentication.
Exemptions can be divided in two categories: issuer exemptions and acquirer exemptions.
Issuer exemptions can be applied directly by the issuer in the following cases:
- Low value transactions: transaction value ≤ 30 EUR
- Transaction Risk Analysis: the issuer performs a risk analysis of the order based on the information available. In case the risk analysis recognizes the transaction as safe, the Issuer may decide to proceed with a frictionless flow.
- White Listing of trusted beneficiaries: if the Issuer supports this function, it will allow the buyer – upon a successful SCA – to whitelist the merchant he is buying from. If the merchant is whitelisted for a card, SCA will not be applied.
- Secure Corporate Payments: these payments are initiated by companies that employ dedicated processes and make use of protocols that grant security levels equivalent to those introduced by SCA.
Acquirer exemptions are requested by the merchant upon agreement with the acquirer.
While Issuer exemptions are directly applied by the Issuer, Acquirer exemptions are requested in the authentication flow and may be accepted or not by the Issuer.
If an acquirer exemption is accepted, a liability shift from the Issuer to the Acquirer will occur ; meaning that the Acquirer will be liable in case of a fraud chargeback on that transaction.
The following acquirer exemptions may be requested:
- Low value transactions: transaction value ≤ 30 EUR. The Issuer will keep track of these transactions and, in case attention thresholds are reached, the exemption request will be refused and SCA applied.
- Transaction Risk Analysis: if the acquirer's fraud rate is within the accepted thresholds, it is possible to request an exemption following a transaction risk analysis made by the merchant (or his provider of choice)
Transaction and integration types
The following transaction types exist in Axerve Ecommerce Solutions [transDetails.type]:
- Ecommerce : these are customer-initiated transactions. It is possible to save the card details by use of a token (card on file) and to use them in future transactions. These transactions are subject to SCA – unless they are out-of-scope - and exemptions may be applied.
- MOTO : this category includes payments made as
- Mail Order
- Telephone order
Since these transactions are out-of-scope, a strong customer authentication is not required.
- Recurring transactions: these are recurring transactions for which a contract is stipulated between merchant and cardholder during the first transaction.
- Recurring First – during the first transaction the buyer must be authenticated by SCA. Furthermore, the minimum days between one payment and the next and the expiry date of the agreement have to be defined
- Recurring Next – these are the transactions following the "Recurring First". These are MIT transactions and for this reason an authentication phase is not required.
- Unscheduled MIT: there are cases when the agreement between the merchant and the buyer does not establish fixed recurring amounts and time intervals between the payments. Such scenarios are common in pay-for-use business models. Unscheduled MITs allow the merchant to initiate payments in such scenarios.
- Unscheduled MIT First - during the first transaction the buyer must be authenticated by SCA. The transaction must be authenticated and authorized for the amount due immediately.
- Unscheduled MIT Next - these are the transactions following the “Unscheduled MIT First”. These are MIT transactions, therefore authentication is not required.
- Authentication only: this is not a payment transaction. This type of operation is made in order to authenticate the cardholder, and an SCA is expected.
According to the type of the interaction with the PSP, the following operations are possible:
- Virtual POS: all transactions made from this environment are considered MOTO
- Payment page: for these payments the presence of the buyer is expected. Therefore, the following transactions can be made from PAGAM page: recurring first, unscheduled MIT first, Ecommerce, authentication only. In case no specific transaction type is specified, the system will assign the Ecommerce value by default.
- Server to Server: this type of integration allows any type of transaction. If no type is specified, the system will assign the default value configured in the merchant registry for the specific shop login.
With a Server to Server integration, it is also possible to:
- request an authentication for a transaction that will be later authorized by another PSP. In this case, the paramenter transTypeReq has to be set to "A" and the response message will contain the information to be used for the authorization. It would still be possible authorize the transaction through Axerve.
- Authorize a payment previously authenticated by a third party 3D Secure provider
threeDSAuthResult. In this case, the response previously gathered by the third party 3D Secure provider have to be sent to Axerve.
Axerve will handle each transaction accordingly to merchant configuration and transaction parameters. The merchant may also express a preference in every single transaction regarding:
- Their wish to exclude the possibility for any exemption to be applied to that transaction and to request a mandatory SCA [exemption = "SKIP"]
- The request of an exemption based upon a transaction risk analysis perfomed by a third party engine or a proprietary one [exemption = "FORCE"]