3DS 2.0 Authentication

What is 3DS 2.0?

In order to minimize the fraud rate without spoiling the conversion rate, the payment industry has developed a new authentication standard called EMV 3DS, or also called 3DS 2.0. The new version is able to analyze dozens of variables that are used as criteria to determine if a shopper is in fact the cardholder, allowing in some cases the silent authentication of the cardholder (authentication without challenge), without harming the establishments’ Liability Shift.

Main Benefits:

Keywords: Credit and Debit Card Authentication, EMVCO, 3DS 2.0, Visa, Mastercard, E-commerce

Who can use 3DS 2.0?

Any business that has e-commerce or an application can use the solution. It is particularly suitable for establishments belonging to the high risk segment.

What are requirements for using 3DS 2.0?

The merchant must meet the following requirements for using 3DS 2.0:

Brands and Issuers Available

For sending transactions with 3DS 2.0 authentication request it is essential that, in addition to Cielo, the Issuer and Brand are ready with the solution. Among the market brands, Visa and Mastercard are currently available in 3DS 2.0 Cielo. Both have a Stand-In model if the Issuer is not yet able to respond to an authentication request using EMV 3DS 2.0. In this scenario, the brand evaluates the submitted data, such as customer behavioral and transactional history, classifying authentication requests as “Low Risk” and “Not Low Risk”. From this information, Issuers can be protected even without having their own 3DS 2.0 solution, and will have greater confidence in authenticated transactions. In Stand-In cases, authentication occurs silently (without challenge to the cardholder) and once the transaction has been authenticated, liability in case of fraud will be held by the Issuer. The decision to authorize the transaction or not is up to the Issuer.

Soon Amex will also be available.

What is Data Only - Notification Only

Data Only is an optional merchant field that can be used exclusively for Mastercard cards. ECI will always be 4.

To use it, the bpmpi_auth_notifyonly field described in item Authentication Step - step 3 - Class Mapping must be parameterized. In the Data Only model, additional 3DS 2.0 fields are mapped the same way, and sent to Mastercard and Issuing Banks, however, without requesting authentication.

The benefit of using Data Only is to enrich the Issuing Banks and Mastercard databases, which will receive more information about the cardholders of each merchant. This field seeks to improve Issuers’ silent authentication and approval rating, given the current context in which the market is evolving into integration with the new 2.0 authentication protocol. In addition, since May 2019, Mastercard charges an additional fee per unauthenticated transaction from the acquirer, which may impact the price negotiated between the acquirer and the merchant. Data Only exempts the amount of fee charged.

Note that in this model, since there is no authentication from the Issuer, the risk of chargeback for fraud is held by the merchant.

How does authorization with 3DS 2.0 authentication work?

The card authorization process authenticated via 3DS 2.0 takes place in two steps:

  1. Step 1: Authentication
  2. Step 2: Authorization

The flow below describes the high level steps:

3DS 2.0 Flow

  1. The cardholder chooses to pay by credit or debit card
  2. The establishment requests authentication through the Cielo solution.
  3. The authentication platform may follow one of two flows: requesting bearer authentication or performing authentication silently. In the first case, the platform will return the Authentication URL to the merchant. In the second case, the next step is already the return with the authentication result.
  4. Store has authentication interface in lightbox (Issuer Authentication URL)
  5. The cardholder authenticates to the issuer (process known as performing the challenge)
  6. The issuer returns the authentication result to the 3DS platform, which in turn sends it to the establishment
  7. The establishment may or may not proceed with the authorization process. When you choose to authorize you must submit the authentication result in the technical authorization
  8. Cielo returns the result of the authorization to the establishment, which, in turn, returns it to the cardholder.


The solution consists of the API access token request step. Click one of the options below to view the manual that best suits your needs:

  1. Authentication via JavaScript: Ideal for deployment on websites
  2. Android SDK Authentication: Ideal for In-App Deployment Android
  3. IOS SDK Authentication: Ideal for In-App Deployment IOS

Authorization with Authentication

After authentication is completed, it undergoes the authorization process by submitting the authentication data in the “external authentication” (node ExternalAuthentication). See more details at: https://braspag.github.io//en/manualp/authorization-with-authentication