3DS 2.0 Authentication
What is 3DS 2.0?
In order to minimize the fraud rate without spoil 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 prejudice to the issue of Liability Shift of establishments.
- Easy integration via Java Script;
- Authentication interface is responsive to mobile;
- Possibility of authentication “silent” (exemption from challenge);
- Minimizes transactions with frauds;
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:
- Have Cielo E-Commerce 3.0 affiliation;
- Complete the technical integration of the authentication flow;
- Complete the technical integration of the authorization flow;
Flags and Issuers Available
For sending transactions with 3DS 2.0 authentication request it is essential that, in addition to 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 is not 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 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 card holder) 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.
Soon Elo and Amex flags will also be available.
|Banco do Brasil||—||Credit/Debit||—|
What is Data Only - Notification Only
Data Only is an optional merchant field that can be used exclusively for Mastercard cards.
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 bearers 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, as of May 2019, Mastercard will charge 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 of the Issuer, the risk of chargeback for fraud remains with 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:
- Step 1: Authentication
- Step 2: Authorization
The flow below describes the high level steps:
- The holder chooses to pay by credit or debit card
- The establishment requests authentication through the Cielo solution.
- The authentication platform may follow one of two streams: 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.
- Store has authentication interface in lightbox (Issuer Authentication URL)
- The card holder authenticates to the sender (process known as performing the challenge)
- The sender returns the authentication result to the 3DS platform, which in turn passes it to the establishment
- 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
- Cielo returns the result of the authorization to the establishment, which in turn returns to the card holder
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:
- Android SDK Authentication: Ideal for In-App Deployment [Android] (https://braspag.github.io/manual/integracao-sdk-android)
- IOS SDK Authentication: Ideal for In-App Deployment [IOS] (https://braspag.github.io/manual/integracao-sdk-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/manual/aautizacao-com-autenticacao[(https://braspag.github.io/manual/autorizacao-com-autenticacao)