3DS Challenge Flow

Intro

Three-Domain Secure (3DS) challenge flows allow a greater degree of flexibility when securing online transactions via 3DS. These flows add an additional layer of authentication, typically requiring cardholders to verify their identity through a separate device or channel, such as a mobile app. As digital payments continue to grow, understanding the mechanics and implementation of 3DS challenge flows aids in reducing fraud while minimizing disruption to the user experience.

For developers and payment system architects, optimizing these challenge flows is not just about security—it’s about striking the right balance between fraud prevention and transaction approval rates. This guide reviews the technical aspects of 3DS challenge flows, exploring best practices for integrating cardholder authentication while maintaining efficiency and user trust.

Prerequisites

1. 3DS challenge flows are an extension of customer 3DS decisioning. Before integrating 3DS challenge flows, card programs must ensure that they have implemented 3DS Decisioning.

Summary 3DS Challenge Flow

To better understand the process of integrating 3DS challenge flows into your Card Program, this section reviews the essential communications between the Cardholder, Lithic, and the Card Program. For a greater degree of detail, the full information flow between all parties is described in detail sections below.

1. The cardholder initiates an online transaction authenticated by 3DS.
2. Lithic sends a 3DS Decisioning Request to the responder endpoint registered by the Card Program.
   1. Note: While Lithic can decision 3DS requests on the Card Program's behalf, 3DS challenge flows require that the Card Program participate in 3DS decisioning by enrolling a 3DS Decisioning Responder.
3. The Card Program responds to the 3DS Decisioning Request with a decision of CHALLENGE_REQUESTED.
4. Lithic sends a challenge event webhook to the Card Program with information pertaining to the challenge.
   1. This new event, three_ds_authentication.challenge, must be consumed by the Card Program. Within this challenge webhook, there is:
      1. authentication_object which contains information about the ongoing 3DS Authentication, including the token which must be used later to respond with the results of the Challenge.
      2. start_time and expiry_time denoting key timestamps relating to the Challenge's TTL.
5. The Card Program issues a challenge to the Cardholder.
   1. It is the responsibility of the Card Program to construct an effective challenge. As examples, Card Programs may choose to challenge their Cardholders via an in-app push notification, SMS, or email message. Regardless of the method, it is the Card Program's responsibility to solicit a response (approve/decline) from the Cardholder.
      1. For more information about cardholder challenges, see Constructing a Cardholder Challenge.
   2. The Card Program must respond to Lithic before the expiry_time found in the three_ds_authentication.challenge webhook. This window is typically 10 minutes.
6. The Card Program responds to Lithic with a Challenge Response of APPROVE or DECLINE_BY_CUSTOMER based on the results of the Cardholder challenge.
7. Depending on the Card Program’s challenge response, Lithic will either proceed with or decline the Cardholder’s authorization.

Detailed 3DS Decisioning Flow

The first step in the Challenge flow starts with the existing Customer 3DS Decisioning Flow. This flow remains the same with one exception:

• a new response value will be added to the existing 3DS Decisioning Response model. In addition to APPROVE and DECLINE, the response valueCHALLENGE_REQUESTED is now available.

See the three_ds_decisioning webhook in the 3DS Challenge Flow Spec for more details on all valid responses.

📄

There is no change to existing behavior when the 3DS Decision is APPROVE or DECLINE.

Detailed 3DS Challenge Flow

Challenges act as an additional authentication step to verify the cardholder’s identity. When the Card Program has requested a challenge as part of a 3DS Decisioning Flow, a Challenge Request will be created by the Directory Server. When Lithic receives the Challenge Request from the Directory Server, Lithic will trigger a new Event Webhook three_ds_authentication.challenge that programs must consume to complete a challenge flow.

• Refer to the Lithic Events API documentation for details on subscribing to specific events or all events.

The Challenge flow is broken into two parts.

1. The triggering of the Challenge Request:
   • Lithic will send the challenge event once the Challenge Request is received from the Directory Server, prompting the Card Program to initiate a challenge directly with the cardholder (e.g., push notification that routes to Card Program’s app to confirm transaction). This is known as an Out-of-Band (OOB) challenge.
     • See three_ds_authentication_challenge in 3DS Challenge Flow Spec for more information on what is included in the challenge event.
2. Forwarding Cardholders Response:
   • Once the Card Program successfully completes the challenge (i.e., receives positive or negative confirmation from the cardholder), the Card Program will send that response to Lithic using the /three_ds_decisioning/challenge_response endpoint.
     • See 3DS Challenge Flow Spec for more information on that endpoint.

Constructing a Cardholder Challenge

When a Card Program elects to challenge their cardholder during a 3DS authentication flow, the Card Program is solely responsible for constructing an effective challenge for the cardholder. To proceed through the challenge flow, only the results of the challenge (whether the cardholder has approved or declined the transaction) must be communicated back to Lithic. This flexibility unlocks several key advantages for the Card Program that can significantly enhance the cardholder experience and improve overall transaction success rates.

• Omnichannel Flexibility: By creating their own challenge, Card Programs can ensure that the authentication process is seamlessly integrated across various channels, including SMS, email, and in-app environments. This flexibility means that cardholders can complete the challenge in the way that is most convenient for them, reducing friction and increasing the likelihood of successful authentication.
• Full Control Over Messaging: Having control over the challenge allows Card Programs to tailor the messaging and user interface to align with their brand identity and the specific needs of their customer base. This consistency in communication can increase trust and comfort for cardholders, making them more likely to complete the challenge.
• Choice of Authentication Methods: Card Programs have the flexibility to choose the type of authentication that best suits their cardholders and risk profiles. They can opt for various methods, such as sending an embedded link via email, requesting a simple “yes” or “no” response via SMS, pushing a notification to the cardholder’s mobile app, or sending a one-time code that must be entered in-app. This ability to select the most appropriate authentication method for a given cardholder can significantly improve challenge completion rates.
• Lower Abandonment Rates: One of the most significant advantages of constructing a custom challenge is the ability to optimize the entire authentication process through careful selection of communication channels, challenge methods, and messaging strategies. Card Programs can experiment with various combinations to identify the most effective approach that minimizes abandonment rates. By continuously refining and adapting these elements based on real-time feedback and data, programs maintain the flexibility to enhance their authentication flows, ensuring that the challenge process remains efficient and user-friendly. This strategic control enables Card Programs to achieve higher completion rates and better overall outcomes.

Response Guidelines

Challenge Expiration

By default, cardholder challenges will only last for ten minutes. This window denotes the time between when the Challenge Request is sent by the Directory Server to when the Result Request is received by the Directory Server, including the time for all intermediary communication. The precise time a given challenge will expire is noted in the three_ds_authentication.challenge webhook as the expiry_time.

Responses not received within the live window will count against abandonment metrics.

Challenge Abandonment

It is important to be aware that card networks may enforce data integrity metrics which measure challenge abandonment. Challenge abandonment is recorded when an appropriate approval response is not received by the Directory Server prior to challenge expiry. Abandonment causes can include, but are not limited to:

• Technical issues preventing the cardholder from receiving the challenge
• Inability for the cardholder to complete the challenge successfully
• No cardholder response
• Cardholder cancelling the transaction (decline response)

In the case of Mastercard, challenge flow abandonment is monitored via MC Data Integrity Monitoring Program Edit Number 8. At the time of writing, the current abandonment rate threshold for the Mastercard Data Integrity Monitoring Program is set at 90%. As a result, penalties may be assessed by the payment network when abandonments exceed 10% of challenges.

📘

Enforced Data Integrity thresholds may change in the future. As always, please review the most up-to-date network documentation before making decisions about your program.

API References

• 3DS Decisioning Request
• 3DS Challenge Webhook
• 3DS Challenge Response