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 for 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) whether a transaction is in the 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 the reason via API.

Merchants who choose Nuvei’s “fully managed mode” enjoy the benefits of using our “exemptions engine”, which provides an optimized yet balanced approach to exemptions. The “exemptions engine” will apply the merchant’s exemption preferences to each transaction, when making the acquiring decisions.

In any event, the Issuer bank has the final word, by accepting or rejecting the exemption request.

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

Low-Value Exemptions

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.

When applying the exemption, the issuer can choose between the €100 cumulative sum, or 5 consecutive transactions.

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

Low-Value Contactless

Low-value contactless transaction (LVT) exemptions are provided for up to €50, with a maximum cumulative sum of €150 or 5 consecutive transactions.

Transaction Risk

Transaction Risk Assessment (TRA) exemptions are calculated by the Nuvei risk team. TRA thresholds are configured based on our acquiring basis points, merchant fraud basis points, and our analysis of merchant fraud rates.

• 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.
• A PSP (payment service provider) applying a TRA exemption must 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, then 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.

MIT Transactions

Special rules of Strong Customer Authentication apply to MIT (Merchant Initiated Transactions) 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.

If the initial/original recurring payment was not processed by the Nuvei payments gateway, then the scheme network ID should be sent as part of the Subsequent transaction Authorization. If the scheme network ID is not provided, then Nuvei sends 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, liability shifts to the issuer bank that authorized the transaction.

Liability shift does not apply to non-fraud-related chargebacks, or Fraud to Sale cases reported by the issuer bank. In these cases, the merchant may still be responsible even when using 3D-Secure.

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 a case where a directory server is not available to return authentication results, a 3D-Secure v2 transaction will still receive a liability shift.

Note, that with most exemption requests, the merchant remains liable for fraud-related chargebacks. Therefore, sending exemption requests should be used wisely when attempting to balance risks 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 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 that is mandated.

** This feature does not support a case where the merchant is using an External MPI or when Issuer wrongly returns 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 biometric verification.
• Fraud chargebacks liability shift.