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.
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
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
messageVersion values received from your server. Collect the
transStatus and send this to your server for the final
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.