Developers

3D-Secure Explained

What is 3D-Secure 2.0?

As part of the new PSD2 and Strong Customer Authentication (SCA) regulations, a new standard of protecting e-commerce transactions has been introduced.

As the share of e-commerce and especially mobile transactions is growing, the industry has been suffering from high chargeback ratios and low approval ratios compared to card present transactions. With the introduction of 3D-Secure 2.0, this gap should be minimized.

The SCA mandate requires 3D-Secure to be applied to all electronic payments – including proximity, remote and mobile payments – within the European Economic Area (EEA). The strong customer authentication mandate is complemented by some limited exemptions that aim to support a frictionless customer experience when transaction risk is low.

3D-Secure 2.0 supports the transfer of rich data for transactions enabling possible risk-based decisions regarding whether to authenticate or not. This means that based on certain criteria, the end user may or may not be asked to perform a ‘challenge’ to ensure their authenticity. The consumer experience has also been simplified and enhanced thanks to the elimination of the preliminary enrollment process and by not requiring the end user to remember as many passwords.

Some advantages of 3D-Secure 2.0 compared to 3D-Secure 1.0 are:

  • Better user experience.
  • Multiple device support, including mobile in-app support.
  • Enhanced data exchange to enable Risk Based Authentication.
  • Stronger and easier user authentication.

Audience

This document serves as a guide for existing Nuvei merchants that process transactions via Nuvei’s REST API service. This guide instructs these merchants on how to transition from 3D-Secure 1.0 to 3D-Secure 2.0 by detailing the additional parameters needed and should be used in addition to the current integration guides.

Strong Customer Authentication

In 3D-Secure 1.0, users could share their static password for 3D authentication, and there was a risk that their password could be stolen. With strong customer authentication implemented using 3D-Secure 2.0, user authentication is nearly flawless. During the authentication with their card issuing bank, cardholders are required to supply two of the following three categories of information:

  • What the customer is: That can be a fingerprint, facial features, DNA signature, iris format, or voice patterns.
  • What the customer knows: This can be a password, sequence, PIN, pass phrase, or even a personal fact, like the name of their first pet.
  • What the customer has: This can be a mobile phone, badge, token, wearable device, or smart card.

Frictionless vs Challenge Customer Authentication

During the 3D-Secure 2.0 authentication, the issuer performs a risk-based analysis to determine whether a transaction should be challenged. A challenge means that the user is presented with an authentication screen of the issuer that follows the Strong Customer Authentication rules. Issuer risk analysis is performed based on the data collected during the transaction, such as device information, transaction information, time zone and various other parameters. If an issuer determines that the transaction is low risk, a frictionless indicator is returned in the authentication response. Frictionless flow means that the transaction is considered 3D authenticated and a liability shift applies, without the need of the user challenge screen.

It is highly recommended that merchants send as many optional parameters as possible during the authentication, as it increases the chance of frictionless flow and better user conversion.

Strong Customer Authentication Exemptions

Not every transaction is subject to strong customer authentication. For example, low-risk and low-value transactions worth less than 30 EUR are exempt. But if low risk payments adding up to over 100 EUR are made on the card, or more than five consecutive transactions take place, strong customer authentication applies. For low-risk transaction exemptions, the risk of a transaction is based on the average fraud levels of the card issuer and the acquirer processing the transaction.

Another type of exemption is applied for merchant whitelisting, i.e. during authentication, when a cardholder can choose to whitelist the merchant. In such case, all subsequent transactions between the specific cardholder and the merchant are exempted.

The intent of PSD2 is to make SCA a requirement for all online transactions. However, there are some exemptions to this mandate, and for any given transaction your acquirer can set an exemption that is most appropriate.

Exclusions and Exemptions

  • Anonymous prepaid cards.
  • Mail order or telephone order (MOTO).
  • Inter or “one leg” transactions.
  • Merchant initiated transactions (MIT).
  • Secure corporate payments.
  • Whitelists of trusted beneficiaries.
  • Recurring transactions (same amount, same payee). The first transaction of the series must always be undertaken with SCA.
  • Low-value transactions: <30 EUR with counter limitation.

Exemption for Low-Value Remote Payments

This exemption applies to remote transactions up to €30 with a maximum cumulative sum of €100, or 5 consecutive transactions since the SCA was last applied.

The issuer is allowed to choose alternatively between the €100 cumulative sum or 5 consecutive transactions for applying the exemption.

This means that SCA must apply only to the sixth and subsequent transactions exceeding the cumulative sum of €100.

Exemption for Low-Value Contactless Payments

Exemptions are provided for low-value contactless transactions (LVTs) up to €50 with a maximum cumulative sum of €150 or 5 consecutive transactions.

Transaction Risk Assessment (TRA) Exemptions

  • If fraud <13 bps up to 100 EUR (and no counter limitation for txs< 30 EUR)
  • If fraud <6 bps up to 250 EUR
  • If fraud <1 bps up to 500 EUR
  • The formula to calculate the reference fraud rate for the application of the TRA exemption is the total value of unauthorized and fraudulent remote card transactions divided by the total value of all remote card transactions.
  • Friendly fraud is not included in the total value of unauthorized or fraudulent remote transactions considered for the calculation of the fraud rates for the application of TRA exemption.
  • Payment Service Provider (PSP) applying the TRA exemption is required to have a fraud level below the reference fraud rate. For example, if the issuer is below the reference fraud rate, but the acquirer is above, the issuer may still apply the TRA exemption. If the acquirer is below the reference fraud rate, but the issuer is above, the acquirer may still apply the TRA exemption.

3D-Secure 1.0 Fallback

While European Issuers should implement 3D-Secure 2.0 protocol by September 2019, issuers outside of Europe may not yet support it.

A merchant should be able to fall back to 3D-Secure 1.0 protocol if 3D-Secure 2.0 is not supported.

Issuers worldwide are expected to support 3D-Secure 2.0 by the end of 2020.

The merchant is required to support both 3D-Secure 1.0 flow and 3D-Secure 2.0 flow.

After using an /initPayment call to check if the card is enrolled in 3D-Secure 2.0, the merchant needs to continue with 3D-Secure 1.0 or 3D-Secure 2.0 Authentication.

Recurring Transactions

Special rules of Strong Customer Authentication apply to subscription transactions. SCA/3D Authentication should be applied for the first authorization that initiated the transaction. The liability shift is applied for this transaction. The frequency of the subscription and expiry date should be sent during the authorization. These parameters should be part of the subscription agreement with the cardholder. If the subscription parameters are about to change, a new agreement should be performed with the cardholder, including SCA authentication. For the subsequent MIT transactions, no SCA is applied as there is no interaction with the cardholder, nor does the liability shift. The first transaction reference, which initiated the subscription, should be sent along with the authorization.

Liability Shift

With 3D-Secure 2.0 Authentication applied, a transaction receives a liability shift from fraud related chargebacks, just like 3D-Secure 1.0.

A liability shift of 3D-Secure 1.0 transactions continues to apply, until the official sunset date, which has not yet been set.

The change in merchant protection when comparing 3D-Secure 2.0 Authentication vs 3D-Secure 1.0 is that when authentication results are returned by server attempts on behalf of a directory server that is not available, the transaction still receives a liability shift.