GENERAL 3DS FLOW
This document covers the process flow in a 3DS (3 Dimensional Secure) system. Three dimensions to a 3DS protocol are: Card Holder, Issuing Bank and Merchant. To explain further let’s take an example.
1. A Customer ‘X’ goes to a website ‘www.Amazon.com’ to purchase an item. The customer orders an item using his HDFC bank credit card. So here ‘X’ is the Card Holder, ‘HDFC Bank’ is the Issuing Bank and ‘www.Amazon.com’ is the merchant.
2. When the customer clicks check out, the customer is directed to the Payment Gateway (PG). The PG will be having a Merchant Plug-in (MPI). The PG will be asking all the details like card number, CVV2, expiry date, etc. The MPI picks up this information and provide card number along with some other important info to Visa Directory Server (VDS) or MasterCard Directory Server (MDS).
The Card number is divided into 3 parts namely Bin, Account Number and Check Value. The first 6 digits of a card number are called Bin, next 9 digits comprise of Account Number and the last digit of the Card Number is the Check Value. BIN is issued by the MasterCard or VISA to the various banks.
3. VDS/MDS understands only BIN. VDS/MDS checks to which bank does BIN belong.
4. The complete card number is then transferred from VDS to the enStage Access Control Server (ACS). Here ACS checks whether the card is valid or not and also checks if it can be authenticated.
This transfer of request from MPI to VDS to ACS is known as Verification Enrolment Request (VEReq).
5. If the customer can be authenticated, ACS sends ‘Y’ (a status flag for Yes), and a URL where the card holder can be authenticated to MPI.
This transfer of response from ACS to MPI thru VDS is known as Verification Enrolment Response (VERes)
6. The MPI redirects the card holder browser to the URL provided by the ACS in VEReq. Card holder now lands on the ACS webpage where he can authenticate himself.
The request for authentication from...