• Documentation
  • API Reference
  • Documentation
  • API Reference
Expand All Collapse All
< BACK TO HOME
  • Online Payments
    • Introduction
    • Choosing an Integration Method
    • Payment Scenarios
    • Flow Diagrams
  • Accept Payment
    • Payment Page (Cashier)
      • Quick Start
      • Input Parameters
      • Output Parameters
      • Payment Page Features
      • Cashier
        • Cashier Events Guide
        • Cashier Features
        • Withdrawal Guide
    • Web SDK
      • Quick Start
      • Nuvei Fields
        • Styling
      • Additional Functions
      • APM Payments
      • Tokenization-Only Flow
      • Scenarios
      • Using ReactJS
        • Full Samples
        • Sandbox Examples
      • FAQs
    • Simply Connect
      • Quick Start
        • UI Customization
        • Payment Customization
        • Advanced Controls
        • Simply Connect Examples
      • Server-to-Server
        • REST 1.0
        • Server SDKs
          • Java SDK
          • .NET SDK
          • PHP SDK
          • Node.JS SDK
      • Mobile SDKs (Beta Release)
        • Android Mobile SDK (Beta Release)
        • iOS Mobile SDK (Beta Release)
      • Marketplaces
      • Self Track
    • Features
      • Authentication
      • Financial Operations
        • Refund
        • Void
        • Auth and Settle
        • Partial Approval
        • Currency Conversion: DCC and MCP
          • Multiple Currency Pricing (MCP)
          • Dynamic Currency Conversion (DCC)
            • DCC in Cashier or Payment Page
            • DCC in REST API Workflows
            • DCC in Web SDK Workflows
        • Payout
        • AFT (Account Funding Transactions)
      • Card Operations
        • Card-on-File
        • PCI and Tokenization
        • Zero-Authorization
        • Merchant-Initiated Transactions (MIT)
        • Blocking Cards
      • Subscriptions (Rebilling)
      • 3D-Secure
        • 3D-Secure Explained
        • 3DS Implementations
          • 3DS MPI-Only Web SDK
          • 3DS MPI-Only REST
          • 3DS External MPI
          • 3DS Responses
          • Challenges and Exemptions
        • 3DS Functions
          • 3D-Secure Fingerprinting
          • 3D-Secure Authentication Challenge
      • Addendums
        • Airline
          • External Authorization
        • Local Payment (Installments)
    • Integration
      • Testing Cards, APIs and APMs
        • Testing Cards
        • Testing APMs
        • Testing APIs with Postman
      • Response Handling
      • Webhooks (DMNs)
        • Payment Transaction Requests
        • Control Panel Events API
      • Payment Facilitators (PayFac)
    • Additional Links
      • FAQs
      • API Reference
      • Release Notes
      • Country and Currency Codes

    3D-Secure Explained

    Home    3D-Secure    3D-Secure Explained

    On this page:
    • Introduction
    • Strong Customer Authentication
      • Information Required for SCA
      • “Frictionless” vs “Challenge”
      • Out of Scope of the SCA
      • SCA Exemptions
        • “Fully Managed Mode”
      • Types of SCA Exemptions
        • Low-Value Exemptions
        • Low-Value Contactless
        • Transaction Risk
        • MIT Transactions
    • Liability Shift
    • Soft Declines
      • Automatic Cascading Mechanism

    Introduction

    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:

    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.

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

    For most exemption requests, the merchant remains liable for fraud-related chargebacks. Therefore, the merchant should send exemption requests wisely, when attempting to balance risks and conversion rates.

    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.

    This feature does not support transactions that involve an External MPI, or for cases where the issuer wrongly returns the “soft decline” in a 3DS 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.
    • Terms of use
    • Privacy Policy
    Nuvei. All rights reserved.