Payment authorization flow with 3DS authentication
The process of authorizing a 3DS authenticated card transaction occurs in two stages:
- Authentication stage: through the 3DS protocol, the card network or issuer authenticates that the shopper is indeed the cardholder. The protocol is integrated into the online store through a JavaScript script, which returns the authentication result and some parameters that must be sent in the authorization. Learn more at [Script Integration];
- Authorization stage: the merchant creates the payment, providing the parameters returned by the script in the authentication stage. Learn more at [Authorization with Authentication].
The following flow describes the authentication stages at a high level:
- The shopper chooses to pay with a credit or debit card;
- The merchant executes a script, requesting to Cielo the authentication through 3DS 2.2 solution;
- Cielo submits shopper’s data to the card network for authentication;
- The card network sends the card data to the issuer, for risk assessment;
- 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; - The issuer sends the authentication result to the 3DS Server;
- 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.
Updated 3 months ago