Introduction to 3D Secure 2

On September 14th 2019, new requirements for authenticating online payments were rolled out in Europe as part of PSD2, or the second Payment Services Directive. As part of this, all European merchants acquiring card transactions need to integrate to 3DS 2.0. Please integrate by March 2020 to avoid an increase in declined transactions.
North American merchants are not required to integrate to 3D Secure 2.0 at this time. Please check this space for all migration notifications

3D Secure 2 provides seamless new ways to authenticate customers while addressing the shortcomings of the existing 3DS 1.0.2 by adding support for mobile applications and for biometric and token validation, and streamlining the checkout experience using “frictionless” authentication.

Paysafe is compliant to 3DS version 2.1.0.

Why Upgrade from 3DS 1.0?

3DS 1.0 was introduced in 2001 as an additional security layer for online purchases. Cardholders would enroll in the card issuer’s 3D Secure program (either Verified by Visa, or Mastercard SecureCode) and create a new password. After enrollment, any subsequent browser-based online transaction would initiate a redirect to the website of the card issuing bank and prompt cardholders to authenticate themselves by providing the enrollment password.

Although this process increased the level of security for card-not-present (CNP) transactions and, in many cases, shifted the liability for fraudulent purchases from the merchant to the issuing bank, it also introduced friction to the checkout process. The authentication redirect, or inline frame, was often interpreted by cardholders as a phishing scam and worked poorly on mobile devices. The additional step of remembering and entering the 3D Secure password also led to higher rates of cart abandonment by cardholders.

3D Secure 2 has addressed these issues by introducing new ways to authenticate the cardholder, including biometric or token validation and “frictionless” authentication.

What's New in 3D Secure 2?

The following table provides a quick overview of the new 3D Secure 2 features.

Features 3DS 1.0.2 3DS2
Browser support
Tablet and mobile support
Seamless app integration
Biometric and token authentication
Rich data transfer
Merchant opt-out flexibility
Non-payment user authentication (subscriptions)
Strong Customer Authentication (SCA) compliant
Fast checkout experience
No enrollment required

What Is "Frictionless" Authentication?

3D Secure 2 enables merchants and banks to share rich contextual cardholder data to quickly authenticate transactions behind the scenes without the additional consumer verification steps that typically cause friction during checkout (e.g., authentication redirects and remembering and entering static passwords). Merchants can now pass in over 100 fields during the authentication request that banks can then use to determine the risk level of the transaction. Using this enriched data transfer, the majority of low-risk transactions can be authenticated without requiring additional input from the consumer, leading to a safe, efficient, and frictionless checkout experience.

Steps in 3D Secure 2 Cardholder Authentication

Once you have set up a Paysafe merchant account, you can connect to the Paysafe Payments Platform with our simple-to-use API. See our Scenarios section for a quick overview of integration options when using the API. Here is a summary of the process:

3D Secure 2 Process Flow

Step A: Collect Device Fingerprint ID
  1. Once the cardholder enters the card details, the merchant initializes the Paysafe 3D Secure 2 JavaScript SDK by calling the start() method and includes the public (single-use token generating) API key and the card BIN.

  2. The JavaScript SDK opens a device fingerprinting session with the Issuer's ACS.

    This step is skipped if the Issuer does not support 3D Secure 2; in that case, the flow will fall back to 3DS 1.0.2.

  3. The JavaScript SDK returns the deviceFingerprintingId to the merchant to use in the Authentication request.

Step B: Authenticate Customer
  1. The merchant submits an Authentication request and includes the required fields along with the deviceFingerprintingId returned in step 3.

  2. Paysafe interprets the directory server response and returns a response to the merchant that contains the status and threeDResult* parameters along with the authenticationId. If status=COMPLETED, then the merchant should consult the Liability Shift matrix to determine whether to proceed with the Authorization request. If status=PENDING and threeDResult=C then the card issuer has challenged the cardholder and requires additional verification.

    * If the bank does not support 3D Secure 2, the API will automatically fall back to 3DS 1.0.2 and the threeDEnrollment parameter will replace threeDResult. See Scenarios and the threeDEnrollment parameter for more details.
Step C: Complete Issuer Challenge (Conditional)
  1. The merchant stores the authenticationId and passes the sdkChallengePayload as a parameter in the challenge() method to the JavaScript SDK.

  2. The JavaScript SDK communicates with the issuer's ACS to handle the challenge.
  3. Once the challenge is complete, the merchant receives a callback from the JavaScript SDK that includes confirmation of the completed challenge along with the authenticationId parameter.

Step D: Make a Payment Authorization Request
  1. The merchant performs a server-to-server lookup using the stored authenticationId to obtain the 3DS Authentication result fields. If status=COMPLETED, then the merchant should consult the Liability Shift matrix to determine whether to proceed with the Authorization request.

  2. The merchant uses the Card Payments API to submit a payment Authorization request, containing the above values along with the original card details.
  3. Assuming these details are passed to the Card Payments API correctly and the card is 3D Secure 2 authenticated, fraud liability is typically shifted from the merchant to the bank.
  • Cardholder Authentication (3D Secure 2) is a recommended step that merchants should implement in regions where the 3D Secure scheme is prevalent, to reduce the risks of fraud and chargebacks.
  • If the response to a 3D Secure authentication is unsuccessful, merchants should consider asking the customer to resubmit their payment or to pay using a different payment method. For more information see 3D Secure 2 Results and Liability Shift.
Did you find this page useful?