Introduction to 3D Secure 2

Effective 15th October 2022, Visa, Mastercard and American Express will discontinue support for 3D Secure 1 and any transaction sent for Authentication with this version will result in an error. It is important to update your integration to 3D Secure 2 (EMV®3-D Secure) now if you are currently on 3D Secure 1 as deadlines are quickly approaching. Please refer to our ‘3D Secure 2’ Page for more information on what you can do to prepare your business: https://www.paysafe.com/en/3ds-2/

It is a mandatory requirement within UK (by FCA) and in European Economic Area (by PSD2) to support Strong Customer Authentication as part of your payment requests. Failing to provide Authentication data or the relevant exemption as part of your transaction will be in breach of those mandates. Please refer to our SCA roadmap for more information. https://www.paysafe.com/en/blog/the-roadmap-to-sca-implementation-in-2021/

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 Group is compliant to 3DS 2.2.0

Why Upgrade from 3DS 1.0?

As with any technology, it becomes obsolete over time. Effective 17th October 2022, Visa, Mastercard, and American Express will no longer support 3D Secure 1. As a result, 3D Secure 1 Strong Customer Authentication (SCA) data will no longer qualify for merchant liability protection, leaving businesses vulnerable to chargebacks and declines with no liability transfer. This protocol version has existed for quite some time and the industry has adopted new requirements that the version can no longer support. Any new requirements have been added to later, newer versions of the protocol developed by EMV Co: 3D Secure 2.1 and 3D Secure 2.2

The 3D Secure 1 version of the protocol has another shortfall. For merchants within European Economic Area and UK planning on running Merchant Initiated Transactions(MITs), where the initial cardholder-initiated transaction was captured with 3D Secure 1 Authentication after the SCA mandate deadline (January 1st 2021 for EEA and March 14th 2022 for UK), they aren’t correctly setting up the necessary Authentication data for any future subsequent MITs. Any merchants looking to process MITs need to upgrade to 3D Secure 2 and request mandatory Step-up Authentication on all initial transactions. The issuing bank will need a reference of the original Authentication had taken place in order to allow any subsequent payments. Any payments that are missing Strong Customer Authentication data (including subsequent ones that have no linked past reference of relationship establishment) will be declined by issuing banks after the mandate enforcement dates.

Another degradation of 3D Secure 1 the industry is seeing is that Visa and MasterCard Stand-in Authentication servers are no longer active and supported, meaning, issuing banks that do not have a 3DS solution in place and making use of Stand-in processing will have to migrate to supporting 3D Secure 2 Stand-in processing.

Starting October 17th 2022 any transactions processing through 3D Secure 1 authentication will fail to authenticate and will lose liability shift protection. This can have an adverse impact on your Acceptance Rates and subsequently your business.

It is a mandatory requirement within UK & EEA to support Strong Customer Authentication as part of your payment requests. Failing to provide Authentication data or the relevant exemption as part of your transaction will be in breach of the mandates.

• Payment API Integration: https://developer.paysafe.com/en/rest-apis/paysafe-payments-api/payments-api/payment-methods/cards/3ds-via-payments-api/

What's New in 3D Secure 2?

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

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 Group merchant account, you can connect to the Paysafe Group 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

4. The merchant submits an Authentication request and includes the required fields along with the deviceFingerprintingId returned in step 3.

5. 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)

6. The merchant stores the authenticationId and passes the sdkChallengePayload as a parameter in the challenge() method to the JavaScript SDK.

7. The JavaScript SDK communicates with the issuer's ACS to handle the challenge.

8. 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

9. 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.

10. The merchant uses the Card Payments API to submit a payment Authorization request, containing the above values along with the original card details.
11. 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.