Decoupled Authentication

Business Overview

Decoupled authentication is a 3DS feature that allows for an alternative authentication method when the primary authentication method (i.e., challenge) is not possible, available or fails.
In the 3DS protocol, the primary authentication method is typically the challenge flow where the Cardholder is directed to their card issuer (ACS) to complete the authentication process. However, there may be situations where the challenge is not possible or successful, for example, when:

  • the Cardholder’s device or browser does not support the required technology (for example, JavaScript not supported, voice assistant) for redirect-based authentication;
  • the ACS authentication is temporarily unavailable or experiencing issues;
  • the Cardholder is unable to complete the authentication process for some reason (for example, poor internet connection, technical difficulties); or
  • the Cardholder is not present, and the Merchant initiates the authentication process with the card issuer, for example, in Mail Order/Telephone Order (MOTO) transactions.

In such cases, the Core Specification allows for a Decoupled Authentication, where the authentication process is performed separately from the payment transaction flow. While the authentication method used for Decoupled Authentication is outside the scope of this White Paper, example methods could include a text message, an email, a phone call, or a push notification to a banking app that completes authentication, and then sends the results to the ACS.

Typically, this involves the following steps:

  1. The Merchant initiates the 3DS authentication process as usual, but the Issuer recognises that the primary authentication method is not available or has failed..
  2. The Issuer then triggers an alternative authentication method, such as prompting the Cardholder to authenticate using a mobile banking app or another secure channel.
  3. The Cardholder completes the alternative authentication process.
  4. The Issuer provides the Merchant with an Authentication Result. Decoupled Authentication ensures that the payment transaction can still be completed, even if the primary 3DS authentication method is not available or fails.

Decoupled Authentication is applicable to all Device Channels, but it is the only authentication method available to facilitate Cardholder challenges for 3RI transactions. This helps to improve the overall user experience and reduce the risk of abandoned transactions.

Note: Although Decoupled Authentication is a 3DS challenge method, the flow may differ from the general Challenge Flow as the CReq/CRes messages are not always present.

Benefits by Actor

3DS Requestor
  • authentication is performed after the checkout process
ACS
  • authentication is possible, also when the device does not support the 3DS challenge (for example, a voice assistant)
  • authentication can use a different channel in case of a fraudulent transaction or compromised device
 
3DS Data Elements Related to Decoupled Authentication

The below table  lists the data elements that may be provided by 3DS Servers and ACSs to support Decoupled Authentication.
For additional information, refer to Table A.1 in the Core Specification and to the EMV 3-D Secure Bridging Message Extension.

Table 4.4: 3DS Data Elements Related to Decoupled Authentication

Data Element

Description

Version

3DS Requestor Decoupled Request Indicator

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

2.3.1.1

2.2

3DS Requestor Decoupled Max Time

Indicates the maximum amount of time that the 3DS Requestor will wait for an ACS to provide the results of a Decoupled Authentication transaction (in minutes).

2.3.1.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.

Note: if the element is not provided, the expected action is for the ACS to interpret as N (Do not use Decoupled Authentication).

2.3.1.1

2.2

3DS Requestor Prior Transaction Authentication Information

Information about how the 3DS Requestor authenticated the Cardholder as part of a previous 3DS transaction.

Required for 3RI in the case of Decoupled Authentication Fallback or for SPC.

2.3.1.1

2.2

3RI Indicator

Indicates the type of 3RI request.

This data element provides additional information to the ACS to determine the best approach for handling a 3RI request.

2.3.1.1

2.2

ACS Decoupled Confirmation Indicator

Indicates whether the ACS confirms use of Decoupled Authentication and agrees to use Decoupled Authentication to authenticate the Cardholder.

2.3.1.1

2.2

Authentication Method

Indicates the list of authentication types the Issuer will use to challenge the Cardholder, when in the ARes message or what was used by the ACS when in the RReq message.

Note: For 03-3RI, only present for Decoupled Authentication.

2.3.1.1

2.2

Card Range Data – ACS Information Indicator

Provides additional information for a particular Protocol Version to the 3DS Server. The element lists all applicable values for the card range.

2.3.1.1

2.2

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” with optionally the Issuer and Payment System images.

Refer to Section A.20 in the Core Specification for UI example.

2.3.1.1

2.2

Challenge Cancelation Indicator

Indicator informing the ACS and the DS that the authentication has been cancelled.

2.3.1.1

2.2

Results Message Status

Indicates the status of the Results Request message from the 3DS Server to provide additional data to the ACS.

This will indicate if the message was successfully received for further processing or will be used to provide more detail on why the Challenge could not be completed from the 3DS Client to the ACS.

2.3.1.1

2.2

Transaction Status

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

The Final CRes message can only contain a value of Y or N or D.

Transaction Status = C or S is not allowed for Device Channel = 3RI.

2.3.1.1

2.2

Transaction Status Reason

Provides information on why the Transaction Status field has the specified value.

2.3.1.1

2.2

3DS Requestor-Initiated Flow (3RI Device Channel)

Overview

The 3DS Requestor needs to authenticate a transaction with the Issuer, but the Cardholder is not present. This may happen in the case of:

  • Mail Order/Telephone Order (MOTO) transactions
  • Recurring transactions/subscriptions
  • Split/delayed shipments
  • Flash sales.

To determine if the ACS supports Decoupled Authentication as an authentication method, the 3DS Server should refer to the ACS Information Indicator data element.

Sequence Diagram

  1. Along with any details about the transaction, 3DS Requestor sets its preferences for Decoupled Authentication using the following elements:
    a. 3DS Requestor Decoupled Max Time
    b. 3DS Requestor Decoupled Request Indicator
    c. 3DS Requestor Prior Transaction Authentication Information
    d. 3RI Indicator
  2. The 3DS Server sends a 3RI Authentication Request (AReq).
  3. The ACS evaluates the transaction and determines if a Cardholder challenge is required and determines if Decoupled Authentication is appropriate given the conditions provided by the 3DS Requestor. The ACS specifies its intent to use Decoupled Authentication as the authentication method in the AReq message using the following elements:
    a. ACS Decoupled Confirmation Indicator
    b. Authentication Method
    c. Cardholder Information Text
    d. Transaction Status
  4. The 3DS Server may notify the 3DS Requestor that Decoupled Authentication will be used as the authentication method.
  5. The ACS authenticates the Cardholder using a method that is separate from the 3DS Challenge Flow.
  6. The ACS provides the results of the authentication in an RReq message.
  7. The 3DS Server receives the authentication results and sends an RRes message.

3DS Requestor-Initiated Flow

Decoupled Authentication as a Challenge Method

Overview

The 3DS Requestor initiates an authentication with the card issuer, the ACS assesses the risk associated with the transaction and selects Decoupled Authentication as challenge method. This may happen if:

  • The ACS knows that it is not possible to use the usual authentication method or to reach the Cardholder.
  • The ACS has assessed that the authentication was initiated from an untrusted or stolen device.

The ACS verifies that Decoupled Authentication is supported by the 3DS Server by checking the 3DS Requestor Decoupled Request Indicator

Sequence Diagram

  1. The Cardholder interacts with the 3DS Requestor website using a Browser or the 3DS Requestor App on a Consumer Device.
  2. The 3DS Requestor initiates communications with the 3DS Server and provides the necessary 3DS data to the 3DS Server to initiate Cardholder authentication.
    Along with any details about the transaction, the 3DS Requestor sets its preferences for Decoupled Authentication using the following elements:
    a. 3DS Requestor Decoupled Max Time
    b. 3DS Requestor Decoupled Request Indicator
    c. 3DS Requestor Prior Transaction Authentication Information
  3. The 3DS Server sends an Authentication Request (AReq).
  4.  The ACS evaluates the transaction and determines if a Cardholder challenge is required and determines if Decoupled Authentication is appropriate given the conditions provided by the 3DS Requestor. The ACS specifies its intent to use Decoupled Authentication in the ARes message as the authentication method by using the following elements:
    a. ACS Decoupled Confirmation Indicator
    b. Authentication Method
    c. Cardholder Information Text
    d. Transaction Status
  5. 3DS Server may notify the 3DS Requestor that Decoupled Authentication will be used as authentication method, and pass the Cardholder Information Text for display to the Cardholder.
  6. The ACS authenticates the Cardholder using a method that is separate from the 3DS Challenge Flow.
  7. The ACS provides the results of the authentication in the RReq message.
  8. The 3DS Server receives the authentication results and sends an RRes message.

Decoupled Authentication as a Challenge Method

Decoupled Authentication Fallback

Overview

During a challenge, the Cardholder or the ACS may experience technical issues that prevent its normal completion. The ACS has the option to invoke Decoupled Authentication as an alternative way to complete the challenge, as long as it is supported by the 3DS Server and the 3DS Requestor.
The Decoupled Authentication Fallback flow is identical to the Decoupled Authentication flow initiated by the Merchant, except it starts after the challenge when the ACS sends Transaction Status = D to the 3DS Requestor in an RReq message. The 3DS Server confirms its support in an RRes message (Result Message Status = 04), and then initiates a 3RI transaction with Decoupled Authentication as the challenge method.

Sequence Diagram

  1. The Cardholder interacts with the 3DS Requestor website using a Browser or the 3DS Requestor App on a Consumer Device.
  2. The 3DS Requestor initiates an authentication with the 3DS Server.
  3. The 3DS Server sends the AReq message indicating its authentication preference (for example, Frictionless or Challenge).
  4. The ACS responds with an Authentication Response (ARes) message requesting a challenge.
  5. The 3DS Server (or 3DS Requestor) accepts to proceed with the challenge (opens an iframe for a Browser-based flow or provides the relevant data to the 3DS SDK for an App-based flow).
  6. The 3DS Client (or 3DS Server) establishes a secure connection with the ACS. Then the ACS proceeds with the challenge and provides instructions to the Cardholder on to how to complete the challenge.
  7. The Cardholder provides the requested information to the ACS to complete the challenge. The ACS evaluates the responses and decides to request Decoupled Authentication Fallback.
  8. The ACS provides the request for a Decoupled Authentication Fallback in a Results Request (RReq) message (Transaction Status =D), the ACS may use the Cardholder Information Text to notify the Cardholder of the Decoupled Authentication.
  9. The 3DS Server acknowledges the Decoupled Authentication Fallback setting Result Message Status = 04 and sends an RRes message.
  10. The 3DS Server notifies the Decoupled Authentication Fallback to the 3DS Requestor, the 3DS Requestor sets its preferences for Decoupled Authentication using the following elements:
    a. 3DS Requestor Decoupled Max Time
    b. 3DS Requestor Decoupled Request Indicator
    c. 3DS Requestor Prior Transaction Authentication Information
    d. 3RI Indicator
  11. The 3DS Server sends a 3RI Authentication Request (AReq).
  12. The ACS evaluates the transaction information, and ACS specifies its intent to use Decoupled Authentication as the authentication method in the ARes message using the following elements:
    a. ACS Decoupled Confirmation Indicator
    b. Authentication Method
    c. Cardholder Information Text
    d. Transaction Status
  13. The 3DS Server notifies the 3DS Requestor that Decoupled Authentication will be used as the authentication method.
  14. The ACS authenticates the Cardholder using a method that is separate from the 3DS Challenge Flow.
  15. The ACS provides the results of the authentication in an RReq message.
  16.  The 3DS Server receives the authentication results and sends an RRes message.

Decoupled Authentication Fallback