3DS 2.0 Authentication

What is 3DS 2.0?

EMV 3DS, also known as 3DS 2.0 is a new authentication technology developed by the payments industry in order to reduce the risk of fraud without harming the conversion rate. This new version analyzes several variables used as a criteria to determine the cardholder authencity, allowing in some cases decreased cardholder authentication interactions (challenges), without risking the merchant’s Liability Shift.

Main benefits:

Key words: Credit and Debit Card Authentication, EMVCO, 3DS 2.0, Visa, Mastercard, E-Commerce

Who is able to use the 3DS 2.0?

All the e-Commerce merchant must adapt itself to the solution from May 2019 for the brands release. The 3DS 2.0 is valid for all the eCommerce transactions, whether it is debit, credit or prepaid card. All the merchants that have a high chargeback/fraud rate, the solution should be even more useful for the benefit of passing the liability shift to the issue bank.

What is required to use 3DS 2.0?

The merchant must attend the below requirements to use 3DS 2.0:

Card Brands and Issuers Available

For transaction sending with 3DS 2.0 authentication request it’s critical that, besides Cielo, the Issuer and Flag are ready with the solution. Among the market flags, Visa and Mastercard are currently available in 3DS 2.0 Cielo. Both have a Stand-In model if the Issuer isn’t yet able to respond to an authentication request using EMV 3DS 2.0. In this scenario, the flag 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 will be able to report on protection even if they don’t have 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 carrier) and once the transaction has been authenticated, liability in case of fraud will be with the Issuer. The decision to authorize the transaction or not is up to the Issuer.

      CARDS BRANDS      
ISSUE BANK MARKET SUPPORT LIST OF BINS ABLE FOR AUTHENTICATION VISA MASTERCAD ELO American Express
Banco do Brasil Under analysis by the issuer Total Credit/Debit Credit/Debit - in replanning Credit/Debit - in replanning Ago/2020
Bradesco Open to the market Partial Credit/Debit Credit/Debit - 30/07 Credit/Debit - in testing phase until 30/07 31/10
Caixa Econômica Open to the market Partial Credit Done
Debit - 4T 2020
Credit - 30/08
Debit - 4T 2020
Credit - 30/08
Debit - 4T 2020
Santander Open to the market Total Credit/Debit Credit/Debit
Itaú Under analysis by the issuer Partial Credit/Debit Credit/Debit
Nubank Under analysis by the issuer Total Credit/Debit Partial - Conclusion 18/07
Banco Original Open to the market Total Credit/Debit Testing
C6BANK Open to the market Total Credit/Debit
Banco Neon Open to the market Total Credit
Acesso Open to the market Total Credit
Porto Seguro Open to the market Total Credit
Pagbank Open to the market Total Credit/Debit Credit/Debit
Midway Open to the market Total Credit
Realize Open to the market Total Credit
Pernambucanas Open to the market Total Credit

What is the Data Only - Notification Only

Data Only is an extra and optional field available to the merchant that can be used exclusively for MasterCard. For this cases the ECI it always be 04.

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

The benefit of using Data Only is to enrich the Issuing Banks and MasterCard database, who will receive more information about the holders of each merchant. This field seeks to improve the Silent Authentication and Issuer approval rating, considering the current context where the market is growing to integrate with the new 2.0 authentication protocol. In addition, from May 2019, Mastercard will charge an additional fee for unauthenticated transaction of the acquirer, which may impact on the price negotiated between Cielo and the merchant. Data Only will exempt the fee charged.

It is worth noting that in this model, since there is no authentication of the Issuer, the risk of chargeback for fraud remains with the merchant.

Payment Flow 3DS 2.0 | With challenge

Flow with challenge 01 Flow with challenge 02

  1. The holder fills the card details at the checkout of the merchant.
  2. The merchant set the 3DS 2.0 solution from Cielo via script for authentication.
  3. Cielo’s 3DS 2.0 solution sends the buyer’s information to the MPI (authentication platform).
  4. MPI communicates with the card brand to process the authentication. The brand identifies the issuer of the card, and sends the buyer’s information for analysis. The issuer identifies the holder as a possible risk, then, requires the challenge and returns the Authentication URL.
  5. A card brand returns an authentication URL to MPI.
  6. MPI returns the authentication URL to the 3DS 2.0 solution.
  7. The 3DS 2.0 solution return the authentication URL to the merchant via script.
  8. The script shows the authentication screen via lightbox.
  9. The holder solve the challenge on the issuer screen.
  10. The issuer returns the authentication result to the card brand.
  11. The card brand return the authentication result to the MPI.
  12. The MPI return the authentication result to the 3DS 2.0 solution.
  13. The 3DS 2.0 solution return the authentication result to the merchant via script (CAVV, ECI e XID).
  14. The merchant sends an authentication request with the authentication data to the API Cielo 3.0.
  15. The API Cielo 3.0 returns the authentication result to the merchant.
  16. The merchant notifies the payment result.

Payment Flow 3DS 2.0 | Without challenge

Flow without challenge

  1. The holder fills the card details at the checkout of the merchant.
  2. The merchant set the 3DS 2.0 solution from Cielo via script for authentication.
  3. Cielo’s 3DS 2.0 solution sends the buyer’s information to the MPI (authentication platform).
  4. MPI communicates with the card brand to process the authentication. The brand identifies the issuer of the card, and sends the buyer’s information for analysis. The issuer identifies the holder as a possible risk, then, requires the challenge and returns the Authentication URL.
  5. The card brand returns the silent authentication result (CAVV e ECI).
  6. The MPI returns the silent authentication result to the 3DS 2.0 solution.
  7. The 3DS 2.0 solution returns the silent authentication result to the merchant via script.
  8. The merchant sends an authentication request with the authentication data to the API Cielo 3.0.
  9. The API Cielo 3.0 returns the authentication result to the merchant.
  10. The merchant notifies the payment result.

How does the authenticated authorization via 3DS 2.0 work?

The authorization process using authentication through 3DS 2.0 occurs in two steps:

  1. Authentication
  2. Authorization

The steps below describes the detailed process:

Fluxo 3DS 2.0

  1. Cardholder choose to pay with credit or debit card.
  2. Merchant requests authentication through Cielo solution.
  3. Authentication platform can perform two ways: request cardholder authentication or perform the 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 is the return with the authentication result.
  4. Merchant presents the authentication interface on lightbox (Issuer Authentication URL).
  5. The cardholder authenticates in the issuer (process known as complete the challenge process)
  6. Card issuer returns authentication result to 3DS platform, which pass it back to the merchant.
  7. Merchant decides if they want to go ahead with authorization process. Once they decide to go ahead, the authentication result must be submitted with the authorization.
  8. Cielo returns the authorization result to the merchant, which passes it to the cardholder.

Authentication - STEP 1. Access Token Request

The solution is composed by the access token request via the API and authentication request via Java Script. Click one of the options below to view the manual that best suits your needs:

  1. Javascript Authentication: ideal for deployment in websites
  2. SDK Android Authentication: ideal for deployment in-app Android in websites
  3. SDK IOS Authentication: ideal for deployment in-app IOS in websites

Authorization with Authentication

After authentication is completed, submit to the authorization procedure, sending the authentication data in the model of quot;external authentication" (node ExternalAuthentication ). See more details at: https://developercielo.github.io/en/manual/autorizacao-com-autenticacao

ECI (E-commerce Indicator)

E-Commerce Indicator (ECI) is returned in the authentication process. This code is an indicator of what exactly occurred in the transaction authentication process. Por meio do ECI, pode-se verificar se a transação foi autenticada e quem foi o agente responsável por aquela autenticação, conforme tabela abaixo: Through the ECI, it’s possible to verify if the transaction was authenticated and who was the agent responsible for that authentication, as shown in the table below:

Brands ECI Transaction Meaning
Visa 05 Authenticated by the Issuing Bank – risk of chargeback becomes of the Issuing bank
Visa 06 Authenticated by the Brand – risk of chargeback becomes of the Issuing bank
Visa Different from 05 and 06 Unauthenticated – risk of chargeback remains with the establishment
Mastercard 01 Authenticated by the Brand – risk of chargeback becomes of the Issuing bank
Mastercard 02 Authenticated by the Issuing Bank – risk of chargeback becomes of the Issuing bank
Mastercard 04 Unauthenticated, transaction characterized as Data Only – risk of chargeback remains with the establishment
Mastercard Different from 01, 02 and 04 Unauthenticated – risk of chargeback remains with the establishment
Elo 05 Authenticated by the Issuing Bank – risk of chargeback becomes of the Issuing bank
Elo 06 Authenticated by the Brand – risk of chargeback becomes of the Issuing bank
Elo 07 Unauthenticated – risk of chargeback remains with the establishment