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

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

threeDSURL: the URL where to redirect the shopper to (optional)

threeDSMethodData: the data to be sent to the threeDSURL (optional)

4a - In case threeDSVersion is 3DS version 1, the 3DSv1 workflow must be followed next

4b - In case threeDSURL and threeDSMethodData are not present in the response, go directly to step 7

4c - In case threeDSURL and threeDSMethodData are present in the response, 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 threeDSServerTransID

8a - If the 3DSAuth returns result code 000, the process is frictionless and the final Sale/Authorize call can be done, go to step 12

8b - If the 3DSAuth returns result code 655, in this case a challenge must be completed by the shopper, go to step 9

8c - For any other result code, the process must stop with an error

9a - If 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

9b - It is possible that, in this step, 3DSecure falls back to v1 (if customer’s credit card issuer bank does not support v2 yet). In such cases, 3DSAuth will return:

The variable PaReq which is the Payer Authentication Request.

The variable ACSUrl which is the URL to 3D Secure Page of the issuing bank .

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

11 - 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

12 - The merchant calls the Sale/Authorize providing 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)