Introduction

As part of the revised Payment Services Directive (PSD2) and Strong Customer Authentication (SCA) regulations, a new standard for protecting e-commerce transactions was introduced.

As the number of card not present (CNP) transactions (including 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 (3DS2) expanded 3D-Secure to all major card networks and is accessible through more devices and platforms including integration with a mobile number that uses a secure passcode for transaction verification. 3DS2 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.

3D-Secure Payment Flow

Frictionless Customer Authentication vs Challenge Flow

3DS2 uses a risk-based authentication process to determine whether a transaction should be challenged. The risk level is calculated by intelligent use of data collected during the transaction, such as device information, time zone, and various other parameters. Frictionless customer authentication is achieved when authentication can be done using only the data collected in the background, allowing the transaction to be processed without requesting any additional information from the customer.

However, if there are risks associated with the transaction, authentication moves on to the extra steps; that is, the “challenge” flow. Users are able to use advanced authentication methods such as biometric information.

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

PSD2 and SCA

The PSD2 applies to transactions where both the issuer and the acquirer are located within EEA. The location of the cardholder and the merchant is not relevant.

What is SCA?

The Regulatory Technical Standards (RTS) define SCA as authentication through at least two out of the following three factors:

• Something only the user knows (e.g. passcode or PIN).
• Something only the user possesses (e.g. mobile phone or token).
• Something the user is (e.g. fingerprint, facial, iris, or eye vein).

For remote transactions, each SCA must be linked to a specific amount and payee (dynamic linking). This requirement, effectively binding authentication to the merchant and the amount, aims at ensuring that a valid authentication code is only used once and for the specific transaction for which the authentication is requested.

The dynamic linking requirements can be summarized as follows:

• The cardholder must be made aware of the merchant details and amount when asked by the Issuer to authenticate herself / himself.
• The authentication code generated by the Issuer can only be used once and must be linked to the specific merchant and amount displayed to the cardholder.
• The authentication code must successfully authenticate only the transaction linked to those specific merchant and amount.
• The resulting cryptographic token must be passed by the Acquirer in the authorization request and must be unique for that specific transaction (mandatory).
• The Issuer must validate the cryptographic token passed in authorization and ensure that there is a match in merchant and amount between the token and authorization.
• If there is no match, the Issuer should decline the transaction.

Exclusions

• SCA is not required for Mail & Telephone order (MoTo), anonymous prepaid, and direct debit transactions.
• RTS do not clarify whether card transactions initiated by the payee only (Merchant initiated transactions “MIT”) are subject to SCA.
  For example:
  • UB payments
  • Pay-Tv and mobile phone subscriptions
  • Car/bike sharing transactions
  • Digital services subscriptions
  • Insurance premium payments
  • Hotel charges
  • Funding transactions for staged wallets

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.

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:

SCA Exemptions

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:

1. Liability remains with the merchant and does not shift to the issuer.
2. 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

Low-Value 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.)

Low-Value Contactless

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

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.

MITs

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 MITs, 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 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.

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.

Soft Declines

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.

Nuvei’s PSD2 Suite

In order to ensure that your processes are fully transparency and that you leverage the SCA as an “opportunity”, choose a “resilient” solution for your business.
Make sure that it contains:

• The Best-of-Breed APIs.
• An entire suite of added value services.