3DS2: the new authentication standard
In order to fight against the increase of e-commerce fraud, the DSP2 European directive has introduced a new method of strong authentication (SCA or Strong Customer Authentication) mandatory as of 14 September 2019.
- Possession: information known only to the client (such as a single-use code),
- Knowledge: information known only to the client (such as a password),
- Inherence: biometric element that identifies the client (such as a device fingerprint, vocal or facial recognition).
SCA is required only if the issuer and the acquirer are both located in the European Economic Area (EEA).
SCA is not applied to transactions made with cards issued outside the EEA, or if the merchant has signed a contract with an acquirer outside the EEA, even if the card was issued in the EEA.
To meet this requirement, a new version of the 3D Secure protocol has been developed: 3D Secure 2 (3DS2).
This new version increases the security of payments and improves the user experience: based on intelligent and dynamic risk analysis, it allows to reduce the number of abandoned transactions that came with 3DS1 by minimizing the amount of communication with the buyer.
To do this, more information (almost 10 times more compared to the previous version, 3DS1) will be used by the issuer in order to evaluate the transaction risks. If the issuer determines that the level of risk for the transaction is low, buyer authentication will be performed without interacting with him or her. In this case, the authentication is “Frictionless”.
If the issuer estimates that the risk for the transaction is high, interaction with the buyer is necessary. In this case, it is a “Challenge”. The challenge will consist in submitting the buyer to at least two of the authentication factors required by SCA.
- This new version supports new payment channels, such as in-app payments and mobile payments
- authentication in pop-in mode replaces redirection to the ACS page.
More information exchanged between the different interlocutors
With 3DS1, only the following information was used to allow cardholder authentication:
Transaction & client details
Contains mandatory or optional information retrieved during the customer journey on the merchant website and using the transaction details:
- card number and expiry date
- billing address
- shipping address
- merchant name
- URL of the merchant website
- MCC code
- acquirer’s BIN
- transaction type
- Authentication on the merchant website Concerns buyer authentication (not 3DS) for access to the merchant website:
- authentication method
- date and time of the connection
- authentication details
- Previous strong authentication 3DS authentication details issued from a previous transaction made by the same cardholder with the same payment method:
- authentication method (frictionless or challenge)
- date and time of 3DS authentication
- authentication details (ACS transaction number)
- Authentication on the merchant website
- Information about the merchant risk
Details that can only be verified by the merchant using the order details and used for risk analysis:
- shipping to the billing address
- store delivery
- shipping e-mail address
- shipping delay
- purchase of gift cards
- available products or pre-order
- first purchase or not
- result of the risk analysis made by the merchant
- Information about the cardholder’s user account
Information relative to the details or the history of the user account on the merchant website:
- date of creation
- date of update
- date of last password change
- number of transactions
- suspicious activity
- Information about the merchant risk
Information about the equipmentInformation about the equipment (browser / native iOS application/ native Android application):
- IP address
- screen size
- time zone
- HTTP headers
- equipment model
- name of the OS
- version of the OS
- date and time
- screen resolution
- GPS coordinates
Depending on the OS, dozens of details can be exploited (IMEI, fonts, Subscriber ID etc.)
Exemptions and merchant preference
DSP2 provides for cases where interaction with the buyer (challenge) will not be necessary:
- transactions of low amounts (< €30),
- low risk transactions,
- installment payments*,
- recurring payments that are limited in time, with fixed installment amounts*.
*strong authentication will be required upon the first installment and will cover the total amount of installments.
However, the issuer can request a strong authentication if 5 or more transactions were made with the same payment amount over the period of 24 hours, or if the total of exempt transactions reaches the amount of €100.
With 3DS2, it will no longer be possible to disable 3DS. However, the merchant can request an exemption in his or her payment request (this is a “merchant preference”).
In this case, if the request is accepted by the issuer, the buyer will not need to authenticate him or herself (no challenge) but the merchant will assume responsibility in case of an outstanding payment (no liability shift to the issuer).
In any case, the issuing bank is the one to determine whether the transaction will be subject to exemption.