3DS Authentication

ℹ️

For the full 3DS documentation, please refer to 3DS Authentication.

What is 3DS authentication?

3DS is an authentication protocol that confirms whether the shopper is indeed the cardholder, before sending the transaction to authorization.

Through 3DS, the carholder data is sent to the card networks and issuers, who will perform the authentication.

The goal of 3DS (also called EMV 3DS) is to prevent fraud in card-not-present (CNP) transactions.

The 3DS authentication is valid for credit and debit card payments.

ℹ️

3DS stands for 3-D Secure Protocol and was developed by EMVCo, a technical body formed by the major card networks that creates specifications for the secure interoperability and acceptance of payments worldwide.

Main benefits

• The liability in case of a chargeback for an authenticated transaction lies with the issuer or the card network;
• Easy integration via JavaScript;
• Possibility of frictionless authentication;
• Minimizes fraudulent transactions.

How to integrate with 3DS authentication

3DS is a script integrated in the merchant's checkout page, that will request the authentication to Cielo 3DS server. When triggered, the script will run the authentication process; when finished, the script output will present the authentication result.

The authentication results should be sent in the authorization request.

1. Generate the script credentials (access_token);
2. Integrate and run the script;
3. Prepare your server to manage the script output parameters (ReferenceId, Xid, Cavv, ECI, Version etc);
4. In the debit or credit card payment, add the parameters for ExternalAthentication\ using the script output (step 3).

ℹ️

For the full 3DS documentation and details on how to integrate, please refer to 3DS Authentication.

3DS authentication flow

The following flow describes the authentication stages at a high level:

1. The shopper chooses to pay with a credit or debit card;
2. The merchant executes a script, requesting to Cielo the authentication through 3DS 2.2 solution;
3. Cielo submits shopper’s data to the card network for authentication;
4. The card network sends the card data to the issuer, for risk assessment;
5. The issuer evaluates the data and determines whether the authentication flow will frictionless or if a challenge will be presented for the cardholder;
   5.1. If the issuer requests a challenge, it creates and sends the URL to the merchant;
   5.2. The merchant presents the challenge lightbox on the checkout page to obtain the shopper’s response;
   5.3. The shopper responds to the challenge, completing the authentication;
6. The issuer sends the authentication result to the 3DS Server;
7. The 3DS Server sends the authentication result. The merchant decides whether to proceed with authorization.

ℹ️

The merchant may choose to submit an unauthenticated transaction for authorization; however, in this case, the chargeback liability remains with the merchant.

Challenge flow vs. frictionless flow

• Challenge flow: the issuer requires the shopper to undergo additional validation, which can be via SMS, token, facial recognition, or biometrics;
• Frictionless: the issuer understands that the analyzed information was enough to identify and authenticate the cardholder or deny the authentication.

DataOnly authentication

Data Only is an optional parameter that can be used to contribute to the network and issuer’s database, improving authentication performance. Data Only transactions are part of the 3DS protocol but are always frictionless and without liability shift (the risk in case of chargeback remains with the merchant).

3DS Data Only is valid for Mastercard and Visa.