Technical Features

This section offers a general introduction to the Challenge Flow and the subsequent sections detail the more complex challenge flows such as SPC, Out-of-Band and Decoupled Authentication. For the common challenge methods such as One-Time Passcode (OTP) or multi-select, please refer to the Core Specification.
After reviewing the information provided in the AReq message, the ACS may decide that further checks are required to complete the authentication. The ACS will respond to the 3DS Server with a Challenge Request (instead of an approval for the Frictionless Flow). For example, a challenge may be necessary because the transaction is deemed high-risk (above a certain threshold) or requires Cardholder authentication due to country mandates or regulations.
The 3DS Requestor can decide whether to proceed with the challenge or terminate the authentication process. For the challenge, the 3DS Client is in direct communication with the ACS through a secure connection, so the ACS can directly interact with the Cardholder for the authentication.

3DS Data Elements Related to the Challenge Flow

Note: There are numerous data elements related to challenge processing. Table 4.1 below only lists those data elements that relate to the 3DS Requestor request in terms of the challenge and response from the ACS. The other data elements depend on the channel (Browser, App) and on the challenge method used by the ACS (OOB, SPC, etc.). For additional information, please refer to the Core Specification or the relevant sections of this White Paper

 

Table 4.1: 3DS Data Elements Related to the Challenge Flow

Data Element/
Field Name

Description

Version

3DS Requestor Challenge Indicator

Indicates whether a challenge is requested for this transaction.

2.3.1

2.2

3DS Requestor Decoupled Request Indicator

Indicates whether the 3DS Requestor requests the ACS to use Decoupled Authentication and agrees to use Decoupled Authentication if the ACS confirms its use.

2.3.1

2.2

ACS Challenge Mandate Indicator

Indication of whether a challenge is required for the transaction to be authorised due to local/regional mandates or other variable.

2.3.1

2.2

Transaction Status

 

Indicates whether a transaction qualifies as an authenticated transaction or account verification.

Note: the ACS uses the Transaction Status to request a Challenge to the 3DS Server

2.3.1

2.2

Sequence Diagram

  1. The Cardholder makes a purchase and proceeds to checkout.
  2. The 3DS Server sends the AReq message indicating its authentication preference (Frictionless, Challenge etc.)
  3. The ACS responds with an Authentication Response (ARes) message requesting a challenge.
  4. The 3DS Server (or 3DS Requestor) accepts to proceed with the challenge (opens an iframe for a Browser flow or provides the relevant data to the 3DS SDK for an App-based flow).
  5. The 3DS Client (or 3DS Server) establishes a secure connection with the ACS. The ACS then proceeds with the challenge and instructs the Cardholder how to complete the challenge.
  6. The Cardholder provides the requested information to the ACS to complete the challenge. The ACS evaluates the responses and decides whether to continue or stop the challenge.
  7. The ACS provides the outcome of the authentication in a Results Request (RReq) message.