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.

3D Secure 2.0 "Frictionless" Authentication Scenario

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.

3D Secure 2.0 Browser-Based Authentication Scenario with Challenge

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.

*The Paysafe 3D Secure 2 API and 3DS JavaScript SDK are capable of supporting card issuers that have not yet transferred from 3DS 1.0.2. The JavaScript SDK is able to interpret the fields based on the 3DS version being used and handle the flow accordingly. This fallback is integrated seamlessly into the JavaScript SDK so you will not need to adjust the authentication flow.

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!

Did you find this page useful?