Domains and Components

The 3D-Secure protocol operates within a model with three domains that communicate with each other, exchanging messages during the authentication process. Each of these domains contains components that fulfill specific roles within the authentication flow.

The domains are as follows:

1. Acquirer Domain: Initiates the authentication flow.

The Acquirer domain includes the following components:

  • 3DS Requestor Environment

    • 3DS Requestor
    • 3DS Client
    • 3DS Server

  • 3DS Integrator

  • Acquirer

    This domain is represented by the 3DSS application.

2. Interoperability Domain: Connects the Acquirer and Issuer domains through messages that contain authentication information.

The Interoperability domain includes the following components:

  • Directory Server (DS)

  • Directory Server Certificate Authority (DS CA)

  • Authorisation System

    This domain is represented by the DS application.

3. Issuer Domain: Transactions are authenticated in this domain.

The Issuer domain includes the following components:

  • Cardholder

  • Consumer Device

  • Issuer

  • Access Control Server (ACS)

    This domain is represented by the ACS application.

3D-Secure Protocol Messages

The 3D-Secure protocol defines a series of request and response messages to provide information about the authentication process's state and the type of flow in which it is located.

The 3DS Server component creates the AReq, RRes, PReq, and Error messages.

Authentication Messages:

AReq (Authentication Request Message): The AReq message is the initial message in the 3D-Secure authentication flow. The 3DS Server creates this message when the authentication process begins. It may contain information about the cardholder, payment, and transaction device.

ARes (Authentication Response Message): The ARes message is the response to the AReq message. It may indicate that the cardholder has been authenticated or that further interaction with the cardholder is required to complete authentication (challenge authentication).

Challenge Messages:

CReq (Challenge Request Message): This message initiates the cardholder's interaction in a challenge flow. It only appears in a flow with friction or challenge.

CRes (Challenge Response Message): This message indicates the result of the authentication or can indicate that further interaction with the cardholder is required to complete authentication. It only appears in a flow with friction or challenge.

Result Messages:

RRes (Results Response Message): The RRes message communicates the result of the RReq message. This message is created and sent by the 3DS Server through the DS to the ACS.

RReq (Results Request Message): The RReq message communicates the results of authentication. This message is sent by the ACS component to the DS and is received by the 3DS Server. This message does not appear in a frictionless transaction.

Preparation Messages:

PReq (Preparation Request Message): The PReq message is created and sent by the 3DS Server to the DS to request information about the ACS and DS. This message is not part of the 3D-Secure authentication message flow.

PRes (Preparation Response Message): The PRes message communicates the results of the PReq message. It is sent by the ACS component to the DS and received by the 3DS Server. This message is not part of the 3D-Secure authentication message flow.

Error Message:

Error Message: Error messages provide additional information about an error that occurred during message processing. These errors can originate from any of the 3D-Secure components.

The 3DS Server component validates the ARes, RReq, and PRes messages.

Message Categories

Messages created by the 3D-Secure Protocol are categorized into two groups:

  • PA (Payment Authentication): Authentication for e-commerce transactions that include payment.

  • NPA (Non-Payment Authentication): Non-payment authentication, used to verify the cardholder's identity and account.

Device Channels

Channels are the means by which a customer can initiate the authentication flow, depending on the device used at the time of the electronic transaction.

The fields in a specific message may vary depending on the device used by the customer.

The possible device channels are as follows:

  • APP: Authentication for a transaction originating from a commerce app or payment gateway.

  • BRW: Authentication for a transaction originating from a commerce website or payment gateway using a browser.

  • RI: Authentication to confirm the account and verify the cardholder's identity. This type of authentication is non-payment and does not require the cardholder's presence. It can be used, for example, to confirm subscriptions.

Authentication Flows

The 3D-Secure protocol contains two possible flows for the cardholder's authentication process:

  • Frictionless Flow:

    The frictionless or no-challenge flow requires no further interaction from the cardholder to achieve successful authentication with 3D-Secure, as the information provided by the cardholder is evaluated as legitimate, complete, and low-risk. Information is considered low risk, for example, when the cardholder registers the same personal data they usually do or fills out the optional authentication fields.

    This flow initiates the 3D-Secure authentication process and consists of sending an authentication request message (AReq), followed by an authentication response message (ARes).

  • Friction or Challenge Flow:

    This flow occurs if the ACS component determines that interaction with the cardholder is necessary to complete authentication. This determination may arise because the transaction is considered high-risk, exceeds certain thresholds, or requires a higher level of authentication due to country mandates or regulations.

    Thus, the frictionless flow transitions to a friction or challenge flow, where the challenge consists of a task presented to the cardholder to verify the legitimacy of their identity and account.

Possible Challenge Types:

  • Challenge Authentication: A form asking the cardholder for additional personal information, verifying a PIN or OTP (One-Time Password) for authentication.

  • Decoupled Authentication: In this authentication, the flow pauses, and the card issuer communicates with the cardholder to verify the provided data through a manual process.

  • Out-of-Band Authentication: The process of verifying the cardholder's data is handled by the card issuer. It may include other forms of authentication like a QR code, a code sent to an app, or biometric authentication.

Regarding the messages present in this type of flow, in addition to the AReq and ARes messages, the friction or challenge flow includes the CReq and CRes messages (except in the case of decoupled authentication) and the RReq and RRes messages.

  • The CReq message is built based on the information received in the ARes message.

  • The CRes message can indicate the result of the authentication or indicate that further interaction with the cardholder is required to complete authentication. This message is the response to the CReq message.

For decoupled authentication, instead of using the CReq and CRes messages, the ACS authenticates the cardholder outside of the 3D-Secure protocol.

  • The RReq message is built based on the information received in the ARes message and communicates the results of the authentication.

  • The RRes message communicates the receipt of the RReq message and the results of authentication and its status.

  • See more details on integration at: Session API Table