- Strong Customer Authentication
- Liability Shift
- Soft Declines
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 have 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 SCA 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 customer may or may not be asked to perform a “challenge” to ensure their authenticity. The customer experience has also been simplified and enhanced thanks to the elimination of the preliminary enrollment process, and not requiring the customer to remember as many passwords.
Some advantages of 3D-Secure v2 compared to 3D-Secure v1 are:
- Better customer experience.
- Multiple device support including mobile in-app support.
- Enhanced data exchange to enable Risk-Based Authentication.
- Stronger and easier customer authentication.
Strong Customer Authentication
Information Required for SCA
In 3D-Secure v1, customers could share their static password for 3D authentication and there was a risk that their password could be stolen. With strong customer authentication implemented in 3D-Secure v2, customer authentication is nearly flawless.
Cardholders are required to supply two of the following three categories of information, during the authentication with their card issuing bank:
- 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, passphrase, 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”
During the 3D-Secure v2 authentication, the issuer performs a risk-based analysis to determine whether a transaction is “frictionless” or should be “challenged”. The analysis is based on data collected during the transaction, such as device information, transaction information, time zone, and various other parameters.
It is highly recommended that merchants send as many optional parameters as possible during the authentication, as it increases the chance of a frictionless flow and better customer conversion.
- If an issuer determines that the transaction is low risk, then a “frictionless” indicator is returned in the authentication response.
A “frictionless” transaction is considered 3D authenticated and liability can shift from the merchant to the issuer, with no need to further authenticate (challenge) the customer.
- A challenge is where the customer is required to authenticate themselves via some form of authentication screen presented by the issuer, which conforms to the SCA rules.
Out of Scope of the SCA
Not every transaction is subject to SCA. Some transactions are “out of the scope of the SCA mandate”, and are not subject to SCA, as described above.
Nuvei (as the acquirer) classifies transactions (in real-time) as “in the scope of the SCA the mandate” or “out of the scope of the SCA the mandate” according to the definition of the PSD2 jurisdiction and the EMVCO.
Out-of-Scope 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
This is a summary of the “In Scope” vs “Out of Scope” Transactions according to RTS Guidelines Published by the EBA:
Before an issuer would be willing to accept liability for a transaction that is subject to SCA, they would need to perform some type of SCA authentication to reduce their chargeback risk. For example, an issuer can require a customer to authenticate themselves by presenting a 3DS authentication challenge pop-up.
However, performing a challenge for every transaction would negatively affect customer experience.
To resolve this conflict of interests between issuer risk and customer experience, Nuvei (as the acquirer) and the merchant are allowed to request the issuer for an “exemption from SCA challenge process” for a transaction, by requesting one of the possible SCA exemptions.
If the issuer approves the exemption request, then:
- Liability remains with the merchant and does not shift to the issuer.
- The transaction is now exempt from (does not need) a customer authentication “challenge” to be performed.
“Fully Managed Mode”
Merchants can also choose to use Nuvei’s “Fully Managed Mode”, and enjoy the benefits of using our “Exemptions Engine”, which provides an optimized yet balanced approach to exemptions. Using the “Exemptions Engine” applies 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.
Types of SCA Exemptions
This exemption applies to remote transactions up to €30, with (the issue can choose either of these definitions):
- A maximum cumulative sum of €100, or
- 5 consecutive transactions since the SCA was last applied.
(This means that SCA should be applied only to the sixth and subsequent transactions exceeding the cumulative sum of €100.)
This exemption applies to low-value contactless transactions (LVT) up to €50, with (the issue can choose either of these definitions):
- A maximum cumulative sum of €150, or
- 5 consecutive transactions.
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.
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.
With 3D-Secure v2 Authentication applied, a payment transaction receives a liability shift for fraud-related chargebacks just like 3D-Secure v1.
In such cases, liability shifts from the merchant to the issuer bank that authorized the transaction.
Liability shift only applies to “fraud-related” chargebacks. Other categories of chargebacks can be still triggered by the Issuer, even after a full 3D secure authentication was performed.
Liability shift does not apply to “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 be relevant 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 receives a liability shift.
When sending a “Straight to Authorization” transaction (without a previous authentication), an issuer bank may return a “soft decline” response. However, the card schemes guidelines do not consider a “soft decline” response to be an “optional response”. Therefore, the guidelines advise that the merchant should re-attempt the request using a 3DS flow.
Automatic Cascading Mechanism
In order to handle these “soft decline” responses, a merchant can choose to use Nuvei’s optional “Automatic Cascading Mechanism” feature which is supported by all of Nuvei’s integration types and should be configured to the merchant’s authentication preferences.
The “Automatic Cascading Mechanism” feature handles “soft declines” by automatically re-generating and sending a new transaction request, according to the merchant’s configured preferences. The new request follows the relevant challenge authentication flow.The “Automatic Cascading Mechanism” feature provides the following benefits:
- Automatic handling of “soft declines” issuer responses.
- Less friction.
- Better optimization for mobile and tablet platforms.
- Enhanced customer experience.
- Minimizes identity theft (improved verification steps).
- Takes advantage of the latest technology innovations for biometric verification.
- Fraud chargebacks liability shift.