3D Secure v2 Implementation


3DS v2 is part of the new Strong Customer Authentication standard that replaces the version 1. The benefits for the shopper is that the process can be transparent without any user interaction. It is the issuer’s responsibility to decide if the shopper must go through a challenge/response process, if not the process is called frictionless and in the end consists in a series of browser redirection.

The issuer needs to have more information on the shopper to be able to decide on the need for challenge or not. For this, there is in the process a redirection to the issuer ACS for it to take a fingerprint of the shopper’s browser. It is also required to provide more detailed information about the order when calling the 3DS directory.

3D Secure v2 Flow





Detailed workflow

This is the details of the workflow that must be implemented by the merchant:

1 - Receive the card information from the shopper through the HTML payment form

2 - Initiate the payment by using the 3DSCheck API call containing all the information about the shopper

3 - The 3DSCheck result returns the following fields:

threeDSVersion: gives the version of the protocol used for information, in case the version is 1 the 3DSv1 workflow must be followed next

threeDSTransactionID: the unique identifier of the transaction that must be provided in every calls

threeDSURL: the URL where to redirect the shopper to

threeDSMethodData: the data to be sent to the threeDSURL

4 - The merchant builds an autosubmit form in an iFrame with the following characteristics:

Action is the threeDSURL received above

Method is POST

A hidden field called threeDSMethodData with as value the threeDSMethodData received above

5 - ACS takes the fingerprint of the shopper environment

6 - ACS redirects the shopper towards the threeDSReturnURL that was transmitted during 3DSCheck call, this URL will receive a POST containing:

threeDSMethodData: information to continue the process

7 - Merchant continues the process by calling the 3DSAuth API call containing threeDSTransactionID

8 - The 3DSAuth call returns:

Result code 000, in this case the process is frictionless and the final Sale/Authorize call can be done

Result code 655, in this case a challenge must be completed by the shopper

Any other result code, the process must stop with an error

9 - If the process is frictionless (received code 000), go directly to the Sale/Authorize call below

10 - It the shopper must go through a challenge, the 3DSAuth returns also:

threeDSURL: the URL where to redirect the shopper to

CReq: the data to be sent to the threeDSURL

In that case the merchant builds an autosubmit form in an iFrame with the following characteristics:

Action is the threeDSURL received above

Method is POST

A hidden field called creq with value as the CReq received above

11 - The challenge is completed at the ACS by the shopper

12 - The ACS redirects the shopper towards the threeDSReturnURL that was transmitted during 3DSCheck call, this URL will receive a POST containing:

cres: the result of the challenge

13 - The merchant calls the Sale/Authorize providing the the CRes received either in 3DSAuth result (frictionless) or after the challenge completion, card information can be omitted in that call (except cardSecurityCode if required)