Scenarios
You can use the 3D Secure 2 REST API to authenticate a cardholder for online CNP purchase requests. This enables you to process mobile or browser-based transactions through the Card Payments API that are fully 3D Secure 2 and SCA compliant.
Browser Flows
See the scenarios below describing the steps in some typical browser-based 3D Secure 2 API processes.
Scenario 1: Browser-Based "Frictionless" Authentication API to use: 3D Secure 2 API + Card API
This scenario illustrates a typical process where the card issuer does not challenge the cardholder and the cardholder is successfully authenticated. This new flow streamlines the consumer checkout experience by reducing additional customer verification steps for low-risk transactions.
Browser Flow with "Frictionless" Authentication
In the scenario above, the merchant uses the 3D Secure 2 API to collect the device fingerprint ID and authenticate the cardholder. The card issuer determines that they have received enough contextual data to proceed with the authentication without requiring additional customer verification (challenge) and returns the status=COMPLETED, threeDResult=Y, and the authenticationId parameters along with other fields. In this case, the merchant should consult the Liability Shift matrix to determine whether to proceed with the Authorization request.
Scenario 2: Browser-Based Authentication with Issuer Challenge API to use: 3D Secure 2 API + Card API
This scenario illustrates a typical process where the card issuer challenges the cardholder and the cardholder is successfully authenticated.
Browser-Based Authentication with Issuer Challenge
In the scenario above, the merchant uses the 3D Secure 2 API to collect the device fingerprint ID and authenticate the cardholder. The card issuer deems the request a high-risk transaction and issues a challenge. The status=COMPLETED, threeDResult*=C, and the sdkChallengePayload parameters are returned to the merchant along with other fields. The merchant passes the sdkChallengePayload though the JavaScript SDK challenge function and then looks up the result using the authenticationId once the challenge is completed. Depending on the result, the merchant should consult the Liability Shift matrix to determine whether to proceed with the Authorization request.
During the fallback procedure, the threeDResult parameter is replaced by the threeDEnrollment parameter to handle the enrollment check required for 3DS 1.0.2.
- If the directory server returns threeDEnrollment=N or U and status=COMPLETED, then the authentication is complete and the merchant should consult the Liability Shift matrix to determine whether to proceed with the Authorization request.
- If the directory server returns threeDEnrollment=Y and status=COMPLETED, then the authentication is complete and the merchant should consult the Liability Shift matrix to determine whether to proceed with the Authorization request.
- If the directory server returns threeDEnrollment=Y and status=PENDING, then the card issuer has challenged the cardholder and the merchant should continue with the challenge flow.
Mobile Flows
Coming Soon!