What is the 3-D Secure Protocol?

The 3-D Secure protocol outlines the infrastructure and components of EMV 3-D Secure, designed to authenticate cardholders during e-commerce transactions. Developed by EMVCo, a global organization, its goal is to ensure secure and interoperable electronic transactions worldwide.

The 3-D Secure authentication protocol is based on a three-domain model, where the Acquirer Domain and Issuer Domain are connected via the Interoperability Domain. These domains exchange a series of messages to authenticate the cardholder during an e-commerce transaction or to verify the cardholder's identity or account in non-payment authentications.

Authentication can occur through either a frictionless or challenge flow. Friction refers to the need for additional cardholder interaction. The ACS component determines the appropriate flow based on the legitimacy of the information provided by the cardholder and the protocol version in use.

Domains and Components

The 3-D Secure protocol is structured around three domains, each with specific components that interact to facilitate the authentication process.

The domains are:

1. Acquirer Domain: Responsible for initiating and completing the authentication flow.

Components:

  • 3DS Requestor Environment
    • 3DS Requestor
    • 3DS Client
    • 3DS Server
  • 3DS Integrator
  • Acquirer

2. Interoperability Domain: Bridges the Acquirer and Issuer domains, relaying authentication messages and information between components.

Components:

  • Directory Server (DS)
  • Directory Server Certificate Authority (DS CA)
  • Authorization System

3. Issuer Domain: This is where authentication decisions are made. The transaction is authenticated here, and the final outcome (successful or not) is determined.

Components:

  • Cardholder
  • Consumer Device
  • Issuer
  • Access Control Server (ACS)

The ACS application represents this domain.

3-D Secure Protocol Messages

The 3-D Secure protocol defines a set of request and response messages to communicate the status of the authentication process and the type of flow in progress.

The ACS component generates the ARes, CRes, RReq, and Error messages.

Authentication Messages

AReq (Authentication Request Message): This is the initial message in the 3-D Secure authentication flow. It is generated by the 3DS Server when the authentication process begins. It may include information about the cardholder, the transaction amount, and the device used.

ARes (Authentication Response Message): This message is the response to the AReq. It indicates whether the cardholder was successfully authenticated or whether additional interaction (challenge flow) is required to complete the authentication.

Challenge Messages

This messages only appears in a friction or challenge-based flow.

CReq (Challenge Request Message): Triggers the cardholder’s interaction in a challenge flow.

CRes (Challenge Response Message): Indicates the result of the authentication or may signal that additional cardholder interaction is needed.

Result Messages

RReq (Results Request Message): Communicates the authentication results. Sent by the ACS to the DS and received by the 3DS Server. There is one RReq per AReq. This message is not present in frictionless transactions.

RRes (Results Response Message): The response to the RReq message, sent by the 3DS Server through the DS to the ACS.

Preparation Messages

PReq (Preparation Request Message): Sent from the 3DS Server to the DS to request information about the ACS and DS, such as card ranges. This message is not part of the core 3-D Secure authentication flow.

PRes (Preparation Response Message): The response to the PReq, containing DS card ranges, active protocol versions for ACS and DS, and the 3DS Method URL for internal updates on the 3DS Server. This message is not part of the core authentication flow.

Error Message

Error Message: Error messages provide additional details about any issue that occurred during message processing. These errors can originate from any component within the 3-D Secure protocol.

The ACS component validates AReq, CReq, and RRes messages.

Device Channels

Device channels refer to the means by which a client initiates the authentication flow, depending on the device used for the electronic transaction.

Message fields may vary depending on the device used by the customer.

Supported device channels include:

  • APP: Authentication of a transaction initiated from a mobile app provided by the merchant or payment gateway.
  • BRW: Authentication of a transaction initiated on a merchant or gateway website using a web browser.
  • RI: Authentication to confirm the cardholder’s identity or account. This is a non-payment authentication and does not require the cardholder’s presence. It can be used, for example, to confirm subscriptions.

Message Categories

Messages defined by the 3-D Secure protocol fall into two categories:

  • PA (Payment Authentication): Used for e-commerce transactions involving payment.
  • NPA (Non-Payment Authentication): Used for non-payment scenarios, such as verifying the cardholder's identity or account.

Authentication Flows

The 3-D Secure protocol supports two possible authentication flows for cardholders:

  • Frictionless Flow:

    The frictionless (or non-challenge) flow does not require additional cardholder interaction for successful authentication. This occurs when the information provided is deemed legitimate, complete, and low-risk. For example, low-risk information may include familiar personal data or when optional authentication fields are completed.

    The frictionless flow begins with an AReq (Authentication Request) and is followed by an ARes (Authentication Response). The frictionless flow is only available in protocol version 2.2.0.

  • Challenge Flow:

    The challenge flow occurs when the ACS determines that cardholder interaction is required to complete authentication. This determination may result from high-risk indicators, exceeding risk thresholds, regulatory requirements, or based on the specific version of the 3DS protocol in use.

    In this case, the flow transitions from frictionless to challenge. A challenge is presented to the cardholder to verify their identity or account legitimacy.

Possible Challenge Types:

  • Challenge Authentication: The cardholder may be presented with a form requesting additional personal information, password verification, or a one-time password (OTP).

  • Decoupled Authentication: The flow is paused, and the transaction enters a decoupled process where the ACS performs manual validations to verify the cardholder's identity. The issuer may be involved in this process.

  • Out-of-Band Authentication: The issuer is responsible for validating the cardholder's data through manual processes, which may include QR codes, app-based codes, biometric authentication, or other methods provided by the issuer.

In addition to the AReq and ARes messages used in the frictionless flow, the challenge flow includes CReq and CRes messages (except in decoupled authentication) and RReq and RRes messages.

  • The CReq message is constructed based on information received in the ARes message.
  • The CRes message indicates the result of the challenge or may signal that further cardholder interaction is required. It is the response to the CReq message.
  • For decoupled authentication, the ACS authenticates the cardholder outside the 3-D Secure protocol, instead of using CReq and CRes messages.
  • The RReq message is constructed based on information from the ARes and communicates the challenge results to the 3DS Server.
  • The RRes message acknowledges receipt of the RReq and communicates the authentication results and status.