Who Should Read This Topic?

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.

“In Scope” vs “Out of Scope” Transactions according to RTS Guidelines Published by the EBA

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.

Nuvei classifies in real time if Transaction is in PSD2 jurisdiction and according to EMVCO if mandated for an SCA or not. Even if it answers the 2 criteria above, the merchant can still request an exemption and elaborate on reason via API, and in case the merchant prefers a fully managed mode, Nuvei implements an exemptions engine to utilize a balanced and optimized approach for exemptions as possible.

In a case when merchant submit his preference, this would be considered by our exemptions engine when determining our acquiring decision per transaction.

No matter what, it is the Issuer bank to have a final word around the exemption request acceptance or not.

Low Value Payment

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.

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 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

TRA thresholds are configured by Nuvei risk team based on our acquiring basis points and based on the analysis of the merchant fraud rates / basis points.

• 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 as long as it is still not yet officially deprecated by schemes. 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 automatically “downgrades” the request to a 3Dv1 payment (or authorization) flow and continues 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, instead of returning a 3D-Secure v2  result, the Nuvei gateway now returns a result using the 3D-Secure v1 template (3D-Secure v1 /payment (the first payment request) or /authorize3d request). The result includes:

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

MIT (Merchant Initiated Transactions) Transactions

Special rules of Strong Customer Authentication apply to MIT or subscription transactions. SCA/3D Authentication must always be applied for the first authorization that initiated the transaction, if originated from a PSD2 jurisdiction and was not yet authenticated. The liability shift is applied only for this transaction. Subsequent transactions should be sent as exemptions with “MIT subsequent” and can skip a strong customer authentication.

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.

In a case when initial/original recurring payment did not happen within Nuvei payments gateway, the scheme network ID should be sent as part of the Subsequent transaction Authorization. In case of an absence, Nuvei prepopulates it with an interim ID provided by the Schemes for its Acquiring option.

Liability Shift

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

In such cases the liability is shifted to the issuer bank who authorized the transaction.

Liability shift does not apply for non-fraud related chargebacks or Fraud to Sale cases reported by the issuer bank. In these cases, the merchant could still be responsible even when using 3DS v1 / v2.

3D-Secure v1 liability-shift transactions 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.

It is important to understand that in Most exemptions requested the merchant remains liable for fraud related chargebacks so those should be used wisely for balancing risk and conversion rates.

Soft Declines

Soft declines may be raised by an issuer bank in a case a Transaction was sent as “Straight to Authorization” without a previous Authentication.

Although in some cases exemptions request can be still sent by a merchant without authentication, this should be considered as an optional response by an issuer and the Guideline by card schemes is re-attempt via a 3DS flow.

Nuvei has created an automatic cascading mechanism that can be configured per merchant and waives the need for a merchant to perform the retry.

This feature works in any type of integration and re-generates a new transaction, which starts with an authentication flow and a challenge request which is mandated.

** Feature would not support a case where merchant is using External MPI or when Issuer wrongly return this decline code in a 3DS flow.

What are the other benefits for merchants?

• Less friction.
• Better optimization for mobile and tablet platforms.
• Enhanced user experience.
• Minimizes identity theft (improved verification steps).
• Takes advantage of the latest technology innovations for a biometric verification.
• Fraud chargebacks liability shift.