3D Secure (Online / Card Not Present / eComm) Transaction Flow

 

While making an online payment, have you ever seen any of the following on the OTP page, depending on the card network you use?

• Visa - Verified by Visa
• Mastercard - Mastercard SecureCode
• American Express (Amex) - Safekey
• Discover and Diners Club International (DCI) - ProtectBuy

Have you ever wondered what these mean? All of them are the proprietary names given by their own networks. Basically they are the 3D Secure protocol.😀

Let us decode them today in this article in the simplest form possible (only functional). I will explain the step-by-step transaction flow of eCommerce / Card Not Present (CNP) / Online transactions.

When you see any of the above logo on the web page where you are making a payment, it means that your transaction is protected by the 3D Secure protocol. This security protocol adds an additional layer of authentication for online transactions to reduce fraud.

If a transaction has happened on 3D Secure protocol, then in case of Chargeback, liability is shifted to the Issuer not on Merchant and Acquirer.

The 3D Secure Transaction has two legs - Authentication and Authorization

Authentication Flow

Authentication and Authorization Complete Flow

Tip: Open the Process Flow Diagram in a different window and read the following steps along with the Process Flow Diagram. Numbering in the Process Flow has been done according to the following steps. This article is not for the experts but those who are new to the Card Payments to make them understand the basic Online Transaction flow. 

From Step 1 to 9 is the Authentication Flow. Step 10 to 16 is the Authorization Flow. 

Authentication Flow

1/ The process start when the cardholder initiates an online purchase by entering payment details on the merchant's website or app.

2.a/ The merchant collects transaction details (like purchase amount and card information) and sends them to the payment gateway (PG).

2.b/ The payment gateway acts as a bridge between the merchant and the 3DS Server to initiate the 3DS process.

3.a/ The payment gateway forwards transaction details to the 3DS Server.

3.b/ The 3DS Server is typically hosted by the acquirer (or a third-party provider), and it orchestrates the 3DS flow by interacting with other entities.

3.c/ The 3DS Server checks whether the card is enrolled in 3DS and determines if authentication is required based on cardholder preferences.

4/ The 3DS Server then contacts the Directory Server associated with the card network (Visa, Mastercard, Discover, DCI etc.) to verify whether the cardholder’s issuing bank participates in 3DS.

5/ The Directory Server responds with information on the card’s 3DS eligibility and directs the 3DS Server to the correct Access Control Server (ACS) if the card is enrolled.

6.a/ The ACS is operated by the issuer (the bank that issued the card) and is responsible for authenticating the cardholder.

6.b/ The ACS presents an authentication challenge to the cardholder, which could be OTP or Biometric or any other Authentication method. It depends on Issuer whether it wants to challenge the Cardholder or allow them to make the transaction frictionless. In India, by Regulation it is mandatory to go with challenge flow, that's the reason we always see the payment page asking for OTP. 

6.c/ The cardholder completes the authentication by providing the requested information, to confirm their identity to ACS.

7.a/ Once cardholder is authenticated (or fails authentication), the ACS sends the result back to the 3DS Server.

7.b/ If authentication is successful, the ACS includes a unique encrypted value as proof. This encrypted value is called 

- CAVV in Visa, Discover and Diners Club

- UCAF in Mastercard

7.c/ If authentication fails, the transaction is declined.

8/ The 3DS Server forwards the authentication result, including the encrypted value, to the payment gateway.

9.a/ The payment gateway includes the encrypted value in the authorization request sent to the acquirer.

9.b/ The acquirer receives the authorization request from the payment gateway, including the encrypted value.

Authorization Flow

10/ The acquirer forwards the authorization request to the card network (like Visa, Mastercard, Discover, DCI etc.).

11.a/ The card network routes the request to the issuer.

11.b/ The issuer receives the authorization request, including the encrypted value.

11.c/ The issuer verifies the encrypted value against its records to ensure that the transaction was authenticated properly.

11.d/ If the encrypted value is valid and the cardholder has sufficient funds, the issuer approves the transaction.

11.e/ If there are issues (e.g., insufficient funds or invalid encrypted value), the issuer declines the transaction.

12/ The issuer sends the authorization response back through the card network.

13/ The card network sends the authorization response back to the Acquirer.

14/ The acquirer then passes the response to the payment gateway.

15/ Finally, the payment gateway sends the result (approved or declined) to the merchant.

16.a/ The merchant receives the authorization response and displays the transaction status to the cardholder.

16.b/ If the transaction is approved, the merchant completes the purchase, confirming the order.

16.c/ If declined, the merchant informs the cardholder, and no further action is taken.

Disclaimer:

• The process flow diagrams included in this blog are original creations by the author, Neeraj Singh. Any reproduction or use of these diagrams requires prior permission from the author.
• Mentions and images of 3D Secure, Verified by Visa, SecureCode, SafeKey, and ProtectBuy are the property of their respective organizations and have been sourced from Google search. All rights to these trademarks and logos belong to their respective organizations.