3DS 2.0 Web SDK

Integrate the 3D Secure 2.0 SDK into your website.

This is a client-side SDK that you embed into the payments page of your website.

The 3D Secure 2.0 authentication process is initiated and completed by your server. The Web SDK manages the fingerprinting of the shopper's device, and presenting a request for additional verification to the shopper.

For more information on the SDK, check out our Web SDK reference.

Embed 3D Secure 2.0 SDK

Download our 3DS 2.0 Web SDK from  GitHub at https://github.com/Adyen/adyen-3ds2-js.

Fingerprint device

When the shopper adds their credit card details, the issuer will fingerprint the shopper's device via a 1x1 iframe. Trigger this by initializing get3DSMethodStatus() with the threeDSServerTransID and threeDSMethodURL values that your server received from the  /authorise  response. Then, collect the threeDSCompInd and send it to your server to authenticate the payment.

When the iframe attempts to POST to the threedsMethodNotificationURL (the 3rd argument in the call to get3DSMethodStatus), the SDK assumes that there is no data that needs to be extracted from the form that the Access Control Server (ACS) POSTs to this URL. This URL then has the control to redirect the page within the iframe to a reachable URL (in the same domain/with the same origin). The front-end can then target the iframe and tell whether device fingerprinting completed successfully.

Handle additional verification request

If your server receives an  /authorise3ds2  response with a resultCode of ChallengeShopper, you'll need to present a request for additional verification to the shopper. This request is generated by the issuer and displayed to the shopper via the iframe. The shopper must complete this verification before the payment can be authorised.

To trigger the request, call doChallenge() with the threeDSServerTransIDacsTransID, and messageVersion values received from your server. Collect the transStatus and send this to your server for the final  /authorise3ds2  call.

Note that:

The SDK expects the passed CReq data (the 2nd argument in the call to doChallenge) to be in the correct form to just be 'stringified'.

An endpoint needs to be running at the notificationURL - the URL that the ACS redirects the challenge iframe to when the challenge is completed. (The notificationURL is passed to the backend in the initial authorise payment call).

This endpoint, which can be running on any domain, needs to be capable of extracting the correct properties from the CRes and appending them as GET params (currently we expect the params transStatus and threeDSServerTransID).

The notificationURL endpoint then needs to redirect the iframe including the expected GET parameters in the URL.

It is the presence of a transStatus parameter in the iframe.location.search property that we use to determine that the challenge has completed.