3D Secure 2.0
3D Secure 2.0 principles
Although it strengthens security by better covering chargeback risks, the 3D Secure V1 protocol is often criticized for its lack of ergonomics. It is responsible for conversions loss of loyal customers and remains inconvenient to authenticate on a smartphone where you have to switch between SMS receiving and code validating on the same screen. 3D Secure 2.0 edition presents itself as a major fix with a promise of enhanced security on all transactions while making the customer journey simpler and friction-free.
For banks, there is no need to systematically request authentication for each transaction. It is now based on risks analysis by exploiting additional data, putting payment in context.
Fraudulent payment risks are better assessed thanks to nearly 150 additional data shared by merchants and sent when the payment is made to the customer’s bank. This new approach makes it possible to avoid strong and systematic authentication. Strong authentication is only done on the issuing bank decision and only for the riskiest transactions.
In addition to and in order to comply with the Payment Services Directive 2 (PSD2), a payment subject to strong authentication (Strong Customer Authentication – SCA*) must reconcile at least 2 of the following information :
- User knowledge
(password, secret question, secret code, identification number, schematic…) - Something in his possession
(mobile phone, connected device, token, smart card, badge) - User unique information that characterizes him
(fingerprint, facial recognition, voice recognition, iris recognition…)
Authentication methods will be subject to gradual changes over time so as not to deteriorate customer habits.
How does 3D Secure 2.0 work?
When paying online, whether via a browser or a smartphone, the cardholder’s bank will conduct a risk assessment based on the contextual analysis of nearly 150 data made available via:
- the phone itself (in the case of a mobile payment)
- the browser
- the market risk
This operation takes place in the background and does not disrupt the payment process, even though the data is sent during the transaction.
More precisely, here is the data that is exchanged and analyzed:
1. For payments made on a smartphone
One or many of the 12 elements common to all mobile platforms, such as:
- the platform type used, along with the carrier IP address
- the device name and model, the screen resolution
- the operating system (also includes OS version)
- the time zone and the device location
2. For payments made from a browser
The data that are gathered from the customer’s browser is, in some cases, similar to the data gathered from a smartphone (see above).
The data are divided into 9 categories:
- Accept Headers: indicates the content type (MIME) that the browser is able to understand.
- IP Address: the IP address of the PC on which the browser is running.
- Java Enabled: indicates if the browser is Java-enabled.
- Language: indicates the language used by the cardholder’s browser.
- Screen Colour Depth: indique la profondeur de la palette de couleurs utilisée pour l’affichage des images à l’écran.
- Screen Height: indicates the total height of the cardholder’s screen in pixels.
- Screen Width: shows the total width of the cardholder’s screen in pixels.
- Time Zone: shows the time difference between UTC and cardholder local time.
- User-Agent: specifies the exact content of the HTTP User-agent header.
3. For the merchant risk analysis
In order to improve the accuracy of risk-based authentication, the bank has the ability to collect and use additional information about cardholders, which is provided by the merchant. Although these additional data are not mandatory, they are strongly recommended.
- The “customer account”:
Pertains to customer data held by the merchant as part of a registered account. This includes basic information such as the account age, the account modification dates, the delivery address, and the transactions frequency, including successful and discontinued transactions. - Purchases:
Refers to the customer’s buying habits, whether the goods or services purchased were previously ordered (new item order indicator), if the order is shipped or not (shipping indicator), and whether the order is purchased in upstream (pre-purchase order indicator). - Past transactions authentication:
Pertains to possible friction during transactions, such as if the cardholder has previously been confronted with an authentication request. Additional information may include the date and time of previous authentication attempts. - Cardholder Merchant Account Authentication:
Refers to the customer login on the merchant account, and to whether the transaction took place on a browser or via a mobile application. Optional information could include credentials relating to the issuer and third-party authentication (e.g. Google). If the existing information is not available to the cardholder, the data is set to Guest mode.
The overall objective is to enrich the transaction process with a maximum of contextual data in order to provide all possible guarantees to the issuer and avoid a strong authentication request.
Deployment Schedule Forecast
1. Europe
Two dates are planned:
- April 2019: responsibility transfer related to the new directive. In other words, if a merchant is able to apply the new strong authentication protocol and the bank is not able to accept it, then the merchant benefits from an automatic liability transfer.
- September 2019: general enforcement of the directive on strong client authentication. More specifically, all European companies are to have implemented and apply the 3D Secure 2.0 protocol.
2. Canada, LAC (Latin America and the Caribbean) & US
- Deployment: august 2019
3. CEMEA (Central Europe, Middle East and Africa)
- Deployment: april 2020
- By the end of 2020, the 3D Secure 2.0 protocol will therefore be implemented on a global scale.
Liability transfer
- 3D Secure 2.0 rules:
The transaction is fully authenticated with 3D Secure 2.0. - Legal Responsibility:
The issuer is responsible for the fraud.
- 3D Secure 2.0 rules:
The merchant is compliant with 3D Secure 2.0, the issuer does not meet the 3D Secure 2.0 metrics. An attempt to authenticate 3D Secure 2.0 has been initiated.. - Legal Responsibility:
The issuer is responsible for the fraud.
- 3D Secure 2.0 rules:
The merchant is fully compliant with 3D Secure 2.0. The transmitter is also in compliance with 3D Secure 2.0. The transaction is not authenticated because of a dispute. - Legal Responsibility:
The issuer is responsible for the fraud.
- 3D Secure 2.0 rules:
The merchant satisfies the rules of 3D Secure 1.0 but not those of 3D Secure 2.0.
A transaction is downgraded to 3D Secure 1.0, which results in full authentication of the cardholder. - Legal Responsibility:
The issuer is responsible for the fraud. Note, however, that 3D Secure 1.0 may not be compatible with PSD2 (Strong Client Authentication), which could result in a slight setback during authorization.
- PSD2 conditions:
Strong authentication not applied.
No exemption applied. - Legal responsibility (Visa, MasterCard):
Refusal therefore no authorization.
- PSD2 conditions:
Strong authentication applied – 3D Secure 2.0 realized.
No exemptions.
. - Legal responsibility (Visa, MasterCard):
The issuer is responsible.
- PSD2 conditions:
Strong authentication applied – The transmitter does not support 3DS 2.0.
No exemptions.
AAV / CAVV attempts are returned to the acquirer. - Legal responsibility (Visa, MasterCard):
The issuer is responsible.
- PSD2 conditions:
The merchant requested a strong authorization exemption via the authentication procedure.
Exemption accepted by the issuer.
No friction. - Legal responsibility (Visa, MasterCard):
The merchant is responsible.
- PSD2 conditions:
The merchant has requested a strong authorization exemption via an authorization procedure.
Without friction. - Legal responsibility (Visa, MasterCard):
The merchant is responsible.
- PSD2 conditions:
Strong authentication applied by the acquirer.
The issuer examines the authentication and chooses to apply an exemption.
Without friction. - Legal responsibility (Visa, MasterCard):
The issuer is responsible.
- PSD2 conditions:
Refusal by the issuer of the strong authentication exemption. - Legal responsibility (Visa, MasterCard):
The issuer is responsible.
Possible exemptions
Strong authentications exemptions are nevertheless foreseen. Examples of the following exemptions include:
1. For payment of less than 30 euros
If a payment is less than 30 euros, an exemption is applied because it is considered as a low value transaction.
However, in excess of 5 cumulated exempt transactions, or if the sum of the transactions exceeds 100 euros, the strong customer authentication may be required.
2. For low risk merchants
As a payment method provider, CentralPay is authorized to perform a real-time risk analysis. It is therefore allowed, if necessary, to impose a strong authentication to the client during a transaction.
CentralPay’s fraud rate analysis takes into account behavior, expenses, purchase scenarios history, customer location and business.
The low-risk exemption applies if the fraud rate thresholds for the indicated amounts are not exceeded.
Fraud rate and amounts:
- Fraud rate of 0.13% for transactions up to 100 euros
- Fraud rate of 0.06% for transactions up to 250 euros
- Fraud rate of 0.01% for transactions up to 500 euros
3. For recurring payments (subscriptions)
For recurring payments, the exemption applies in the following cases:
- 1st highly authenticated transaction.
- Subsequent transactions without authentication if they are in the same amount and from the same merchant.
- Transactions initiated by the merchant as a result from an explicit agreement (a mandate) established between the merchant and the customer regarding the transactions frequency. It should be noted that this covers recurring transactions. In this scenario, strong authentication is only required when setting the mandate.
4. For trusted beneficiaries, merchants listed on whitelist
The customer can whitelist merchants whom he trusts. Merchants thus authenticated as “trusted beneficiaries” are added to a list which is updated by the customer’s bank. It should be noted that the strong customer authentication is necessary during the first transaction but not for the following ones. It is also necessary during the creation, confirmation and modification of the whitelist. Using the client’s last strong authentication as a reference, whitelisting, which applies to card payments and bank transfers, allows for greater flexibility with respect to amounts, number of transactions, and payment period.
5. For business card payments
This exemption covers transactions made by virtual card numbers or business cards used to manage employee travel expenses with online travel agents.
Only the cardholder bank is authorized by the regulations in effect to request this exemption, as neither the company nor the payment method provider can identify the ownership of the card.
6. For MOTO transactions
Mail Orders & Telephone Orders (MOTO) transactions do not fall into the category of electronic payments. They are therefore exempted from a strong customer authentication procedure.
7. For transactions outside Europe
The transaction is exempt if the issuer or acquirer of a transaction is not located in Europe. Once the PSD2 guidelines are implemented, transactions from non-European buyers are likely to be accepted.
Implications for sellers
CentralPay has integrated all the necessary steps into its processes in order to enable you to take advantage of this new 3DS version: a more secure, improved payment experience.
Our services are thus 100% compatible with PSD2 and 3D SECURE 2.0.
