Who should read this section?

This guide steps existing Nuvei merchants, who process transactions via Nuvei’s REST API service, through the transition from 3D-Secure v1 to 3D-Secure v2. It describes the additional steps and parameters needed and should be used in addition to the existing integration guides.

What is 3D-Secure v2?

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 v2, 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 v2 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 v2 compared to 3D-Secure v1 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.

Strong Customer Authentication

In 3D-Secure v1, 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 v2, 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 v2 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 v1 Fallback

Issuer Support for 3D-Secure v1

European issuers were expected to implement the 3D-Secure v2 protocol by September 2019, and issuers in some other parts of the world, by the end of 2020.

However, there are issuers who do not yet support the 3D-Secure v2 protocol, or may not be required to support it, in their part of the world.

A merchant should be able to “fall back” to 3D-Secure v1 protocol, if 3D-Secure v2 is not supported. Therefore, merchants should implement support for both the 3D-Secure v1 and v2 flows.

You can use the /initPayment request to check if a card is enrolled in a 3D-Secure v2 program, and then continue the authentication using the relevant flow, either 3D-Secure v1 or v2.

Downgrading (Cascading) from 3D-Secure v2 to v1

A 3D-Secure v2 payment (or authorization) request may sometimes fail for some technical reason. In such a case, the Nuvei gateway will automatically “downgrade” the request to a 3Dv1 payment (or authorization) flow, and will continue to process it as a 3D-Secure v1 request, because it may still be able to pass as a 3D-Secure v1 request.

In such a case, the result will now be for a 3D-Secure v1 /payment (the first payment request) or /authorize3d request will include:

• • The parameter: cascadedTo3Dv1 = true – to indicate that a downgrade was performed, .
  • The 3Dv1 output fields, for example: acsUrl, paRequest, eci,  etc.
  • (The cascadedTo3Dv1 flag will also be included in the DMN sent to the merchant.)

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 v2 Authentication applied, a transaction receives a liability shift from fraud related chargebacks, just like 3D-Secure v1.

3D-Secure v1 liability-shift transactions will continue to apply until the official sunset date, which has not yet been set.

Merchant protection when using 3D-Secure v2 differs from 3D-Secure v1. In as case where authentication results are returned by server attempts on behalf of a directory server, that is not available, when using 3D-Secure v2 the transaction still receives a liability shift.