FeaturesBlogPricing
Search…
Overview
Get started with PCI Proxy
Collect & store cards
Use stored cards
3D Secure v2
Authentication only
Testing 3D Secure
Errors
3DS Terminology
Network Tokens (beta)
Document Vault (beta)
Resources
Test credentials
Guides
PCI Proxy Dashboard
Receiver PCI DSS compliance validation
Release notes
Have a Question?
FAQ
Contact us
Booking.com IP Whitelist
Powered By GitBook
3DS Terminology

Directory Server (DS)

A server component operated in the Interoperability Domain; it performs a number of functions that include:
    authenticating the 3DS Server
    routing messages between the 3DS Server and the ACS
    validating the 3DS Server, the 3DS SDK, and the 3DS Requestor.

Issuer

A financial institution that issues payment cards, contracts with Cardholders to provide card services, determines eligibility of Cardholders to participate in 3-D Secure, and identifies for the Directory Server card number ranges eligible to participate in 3-D Secure.

Access Control Server (ACS)

A component that operates in the Issuer Domain, that verifies whether authentication is available for a card number and device type, and authenticates specific Cardholders.
The ACS contains the authentication rules and is controlled by the Issuer. ACS functions include:
    Verifying whether a card number is eligible for 3-D Secure authentication
    Verifying whether a Consumer Device type is eligible for 3-D Secure authentication
    Authenticating the Cardholder or confirming account information.

Access Control Server User Interface (ACS UI)

The ACS UI is generated during a Cardholder challenge and is rendered by the ACS within a Browser challenge window.

Merchant

Entity that contracts with an Acquirer to accept payment cards. Manages the online shopping experience with the Cardholder, obtains card number, and then transfers control to the 3DS Server, which conducts payment authentication.

Attempts

In this specification, used to indicate the process by which proof of an authentication attempt is generated when payment authentication is not available. Support for Attempts is determined by each DS.

Frictionless

The process of authentication achieved without Cardholder interaction.

Challenge Flow

A 3-D Secure flow that involves Cardholder interaction

Authorisation

A process by which an Issuer, or a processor on the Issuer's behalf, approves a transaction for payment.

3DS Messages

Authentication Request Message (AReq)

The AReq message is the initial message in the 3-D Secure authentication flow. The 3DS Server forms the AReq message when requesting authentication of the Cardholder. It can contain Cardholder, payment, and Device information for the transaction. There is only one AReq message per authentication.

Authentication Response Message (ARes)

The ARes message is the Issuer’s ACS response to the AReq message. It can indicate that the Cardholder has been authenticated, or that further Cardholder interaction is required to complete the authentication. There is only one ARes message per transaction.

Challenge Request Message (CReq)

An EMV 3-D Secure message sent by the 3DS SDK or 3DS Server where additional information is sent from the Cardholder to the ACS to support the authentication process and to carry the authentication data from the Cardholder.

Challenge Response Message (CRes)

The ACS response to the CReq message. It can indicate the result of the Cardholder authentication or, in the case of an App-based model, also signal that further Cardholder interaction is required to complete the authentication.

Results Request Message (RReq)

The RReq message communicates the results of the authentication or verification. The message is sent by the ACS through the DS to the 3DS Server. There is only one RReq message per AReq message. The RReq message is not present in a Frictionless transaction.

Results Response Message (RRes)

Message sent by the 3DS Server to the ACS via the DS to acknowledge receipt of the Results Request message. This message is not part of the 3-D Secure authentication message flow.

Authentication Flows

Frictionless Flow

The Frictionless Flow initiates a 3-D Secure authentication flow and consists of an AReq message and an ARes message. The Frictionless Flow does not require further Cardholder interaction to achieve a successful authentication and complete the 3-D Secure authentication process. Frictionless flow allows the issuer to approve a transaction without cardholder interaction based on risk-based-authentication performed in the ACS.
The frictionless flow comprises these following steps:
The cardholder initiates a transaction and provides the necessary information for the authentication.
    1.
    Within the 3DS Requestor Environment, the necessary 3-D Secure information is gathered and provided to the 3DS Server for inclusion in the AReq message.
    2.
    3DS Server through DS to ACS—Using the information provided by the Cardholder and data gathered within the 3DS Requestor Environment, the 3DS Server creates and sends an AReq message to the DS, which then forwards the message to the appropriate ACS.
    3.
    ACS through DS to 3DS Server—In response to the AReq message, the ACS returns an ARes message to the DS, which then forwards the message to the initiating 3DS Server. Before returning the response, the ACS evaluates the data provided in the AReq message. In a Frictionless Flow, the ACS determines that further Cardholder interaction is not required to complete the authentication.
    4.
    3DS Requestor Environment—The 3DS Server communicates the result of the ARes message to the 3DS Requestor Environment which then informs the Cardholder.

Challenge Flow

If the ACS determines that further Cardholder interaction is required to complete the authentication, the Frictionless Flow transitions into the Challenge Flow. For example, a challenge may be necessary because the transaction is deemed high-risk, is above certain thresholds, or requires a higher level of authentication due to country mandates (or regulations). 3DS Requestors decide whether to proceed with the challenge, or to terminate the 3-D Secure authentication process.
The challenge flow comprises the following steps:
The cardholder initiates a transaction and provides the information necessary for the authentication.
    1.
    Within the 3DS Requestor Environment, the necessary 3-D Secure information is gathered and provided to the 3DS Server for inclusion in the AReq message.
    2.
    3DS Server through DS to ACS—Using the information provided by the Cardholder and data gathered within the 3DS Requestor Environment, the 3DS Server creates and sends an AReq message to the DS, which then forwards the message to the appropriate ACS.
    3.
    ACS through DS to 3DS Server—In response to the AReq message, the ACS returns an ARes message to the DS, which then forwards the message to the initiating 3DS Server. Before returning the response, the ACS evaluates the data provided in the AReq message. The ARes message indicates that further Cardholder interaction is required to complete the authentication.
    4.
    3DS Requestor Environment—The 3DS Server communicates the result of the ARes message to the 3DS Requestor Environment; further Cardholder interaction is required to complete the authentication.
    5.
    3DS Client to ACS—The 3DS Client initiates a CReq message based on information received in the ARes message. CReq message is formed by the 3DS Server and is posted through the Cardholder’s browser by the 3DS Requestor to the ACS URL received from the ARes message.
    6.
    **ACS to 3DS Client - **The ACS receives the CReq message and interfaces with the 3DS Client to facilitate Cardholder interaction. The ACS sends the authentication user interface to the Cardholder browser. The Cardholder enters the authentication data via the browser to be checked by the ACS. In response to the CReq message, the CRes message is formed by the ACS and sent to the 3DS Server to indicate the result of the authentication.
    7.
    ACS through DS to 3DS Server—The ACS sends an RReq message that can include the Authentication Value (AV) to the DS, which then routes the message to the appropriate 3DS Server using the 3DS Server URL received from the AReq message.
    8.
    3DS Server through DS to ACS—The 3DS Server receives an RReq message and in response, returns an RRes message to the DS, which then routes the message to the ACS.

3DS Data Elements

acquirerBIN - Acquirer BIN

Acquiring institution identification code as assigned by the DS receiving the AReq message.
    Length: Variable, maximum 11 characters
    Data type: string

acquirerMerchantID - Acquirer Merchant ID

Acquirer-assigned Merchant identifier. This may be the same value that is used in authorisation requests sent on behalf of the 3DS Requestor and is represented in ISO 8583 formatting requirements.
    Length: Variable, maximum 35 characters
    Data type: string

mcc - Merchant Category Code

DS-specific code describing the Merchant’s type of business, product or service.
    Length: 4 characters
    Data Type: String
    This value correlates to the Merchant Category Code as defined by each Payment System or DS.

merchantName - Merchant Name

Merchant name assigned by the Acquirer or Payment System.
    Length: Variable, maximum 40 characters
    Data Type: String

authenticationValue - Authentication Value

Payment System-specific value provided by the ACS or the DS using an algorithm defined by Payment System. Authentication Value may be used to provide proof of authentication.
    Length: 28 characters
    Data type: String
    Value accepted: A 20-byte value that has been Base64 encoded, giving a 28-byte result.

dsTransID - DS Transaction ID

Universally unique transaction identifier assigned by the DS to identify a single transaction.
    Length: 36 characters
    Data type: String
    Value accepted: Canonical format as defined in IETF RFC 4122. May utilise any of the specified versions as long as the output meets specified requirements.

messageVersion - Message Version Number

Protocol version identifier This shall be the Protocol Version Number of the specification utilised by the system creating this message. The Message Version Number is set by the 3DS Server which originates the protocol with the AReq message. The Message Version Number does not change during a 3DS transaction.
    Length: Variable, 5–8 characters
    Data type: String

transStatus - Transaction Status

Indicates whether a transaction qualifies as an authenticated transaction or account verification. Note: The Final CRes message can contain only a value of Y or N. Note: If the 3DS Requestor Challenge Indicator = 06 (No challenge requested; Data share only), then a Transaction Status of C is not valid.
    Length: 1 character
    Data type: String
Possible values:
    Y = Authentication Verification Successful.
    N = Not Authenticated/Account Not Verified; Transaction denied.
    U = Authentication/Account Verification Could Not Be Performed; Technical or other problem, as indicated in ARes or RReq.
    A = Attempts Processing Performed; Not Authenticated/Verified, but a proof of attempted authentication/verification is provided.
    C = Challenge Required; Additional authentication is required using the CReq/CRes.
    R = Authentication/Account Verification Rejected; Issuer is rejecting authentication/verification and request that authorisation not be attempted.

threeDSServerTransID - 3DS Server Transaction ID

Universally unique transaction identifier assigned by the 3DS Server to identify a single transaction.
    Length: 36 characters
    Data type: String
    Value accepted: Canonical format as defined in IETF RFC 4122.

cardholderInfo - Cardholder Information Text

Text provided by the ACS/Issuer to Cardholder during a Frictionless or Decoupled transaction. The Issuer can provide information to Cardholder. For example, “Additional authentication is needed for this transaction, please contact (Issuer Name) at xxx-xxx-xxxx.”
    Length: Variable, maximum 128 characters
    Data Type: String
    Note: If field is populated this information is required to be conveyed to the cardholder by the merchant.

transStatusReason - Transaction Status Reason

Provides information on why the Transaction Status field has the specified value.
    Length: 2 characters
    Data Type: String
    Values accepted:
      01 = Card authentication failed
      02 = Unknown Device
      03 = Unsupported Device
      04 = Exceeds authentication frequency limit
      05 = Expired card
      06 = Invalid card number
      07 = Invalid transaction
      08 = No Card record
      09 = Security failure
      10 = Stolen card
      11 = Suspected fraud
      12 = Transaction not permitted to cardholder
      13 = Cardholder not enrolled in service
      14 = Transaction timed out at the ACS
      15 = Low confidence
      16 = Medium confidence
      17 = High confidence
      18 = Very High confidence
      19 = Exceeds ACS maximum challenges
      20 = Non-Payment transaction not supported
      21 = 3RI transaction not supported
      22 = ACS technical issue
      23 = Decoupled Authentication required by ACS but not requested by 3DS Requestor
      24 = 3DS Requestor Decoupled Max Expiry Time exceeded
      25 = Decoupled Authentication was provided insufficient time to authenticate cardholder. ACS will not make attempt
      26 = Authentication attempted but not performed by the cardholder
      27–79 = Reserved for EMVCo future use (values invalid until defined by EMVCo)
      80–99 = Reserved for DS use

eci- Electronic Commerce Indicator

The Electronic Commerce Indicator is a Payment System-specific value provided by the ACS or DS to indicate the results of the attempt to authenticate the Cardholder.
    Length: 2 characters
    Data Type: String
Source: The official EMVCo 3D specification 2.2.0 https://www.emvco.com/emv-technologies/3d-secure/​
Previous
Errors
Next
Network Tokens (beta)
Last modified 4d ago
Copy link
Contents
3DS Messages
Authentication Flows
3DS Data Elements