Decoupled Authentication in EMV 3DS: Implementation Guide

Not every payment transaction takes place in a browser with a cardholder actively waiting for an authentication prompt. IoT devices, smart kiosks, digital wallets initiating recurring charges, and voice-activated payment interfaces all create authentication scenarios where the traditional 3DS challenge flow — a real-time redirect or in-app prompt — is either technically infeasible or would create an unacceptably poor experience.

Decoupled authentication addresses this gap. First introduced in EMV 3DS version 2.2.0 (published by EMVCo in 2018) and significantly enhanced in version 2.3 (October 2021, with the 2.3.1.1 update following in May 2023), decoupled authentication enables the 3DS challenge to be delivered asynchronously — on a separate device, at a later time — extending 3DS coverage to transaction environments previously outside the protocol’s scope. GPayments, which has specialised in 3-D Secure since 1999, supports decoupled authentication through both ActiveServer (3DS Server) and ActiveAccess (Access Control Server).

What Decoupled Authentication Means

In a standard EMV 3DS 2.x challenge flow, the authentication challenge is synchronous: the cardholder is presented with a step-up prompt — an OTP, biometric verification, or push approval — during the payment session, and the merchant waits for the outcome before proceeding. Decoupled authentication breaks this synchronous dependency. The authentication challenge is sent to the cardholder’s banking app as an asynchronous notification, and the cardholder can complete it on a separate device or at a later time, up to a defined maximum timeout period (configurable up to 10,080 minutes — seven days — via the threeDSRequestorDecMaxTime parameter in the EMV 3DS specification).

The flow works as follows: the 3DS Server initiates a decoupled authentication request; the issuer’s ACS evaluates the transaction and confirms decoupled authentication via the ACS Decoupled Confirmation Indicator (transaction status “D”); the ACS delivers the challenge asynchronously to the cardholder; and the authentication result is returned to the 3DS Server via an RReq message when complete — or a timeout is returned if the cardholder does not respond within the configured period.

Key Use Cases for Decoupled Authentication

MOTO and Subscription Payments

Mail order/telephone order (MOTO) transactions and subscription-based payments are the most established use cases for decoupled authentication. In MOTO scenarios, the cardholder is on the phone or has submitted an order by mail — there is no browser or app session to present a synchronous challenge. Decoupled authentication enables the issuer to send a push notification to the cardholder’s registered mobile device for approval, bringing 3DS coverage (and liability shift) to a transaction type that was previously outside the protocol’s reach.

For recurring merchant-initiated transactions (MITs), decoupled authentication can be used when a subsequent transaction exceeds the recurring exemption thresholds or when the initial SCA mandate needs to be refreshed. EMVCo’s white paper specifically identifies subscription-based merchants confirming account validity as a core decoupled authentication scenario.

Unattended Payment Terminals and Kiosks

Digital kiosks, vending machines, transport ticketing terminals, and automated retail environments cannot display a browser-based or app-based challenge. Decoupled authentication enables out-of-band verification on the cardholder’s registered mobile device. This extends 3DS authentication — and its associated liability shift — to unattended payment environments where the device itself has no authentication interface.

Emerging IoT and Connected Device Scenarios

Connected vehicles purchasing fuel, tolls, or parking; smart home devices initiating utility payments; and voice-activated payment interfaces are emerging scenarios where decoupled authentication could apply. These use cases are at earlier stages of commercial deployment, but the protocol infrastructure to support them exists in EMV 3DS 2.2 and later. As issuer ACS adoption of decoupled flows matures, these scenarios will become increasingly viable.

Implementation Considerations

3DS Server Requirements

Implementing decoupled authentication requires a 3DS Server that supports EMV 3DS 2.2.0 or later (2.3 recommended for new implementations). The 3DS Server must manage the pending authentication state — maintaining the transaction context during the period between the decoupled request and the authentication result — and handle timeout scenarios gracefully. Key data elements include the 3DS Requestor Decoupled Max Time, the 3DS Requestor Decoupled Request Indicator, and the ACS Decoupled Confirmation Indicator.

GPayments’ ActiveServer supports decoupled authentication flows with full asynchronous state management, configurable timeout handling, and support for the RReq/RRes result notification mechanism. ActiveServer is EMVCo-certified across all major card schemes and available as a hosted service or for on-premise deployment.

ACS Requirements

On the issuer side, the ACS must support decoupled authentication flows and have a mechanism to deliver out-of-band challenges to cardholders — typically via push notification to the issuer’s mobile banking app. The ACS uses the ACS Decoupled Confirmation Indicator to signal its intent to use decoupled authentication, and returns results via the RReq message when the cardholder completes (or fails to complete) authentication.

GPayments’ ActiveAccess is an ACS solution supporting decoupled authentication, multi-factor authentication (biometric, OTP, push), and risk-based authentication with flexible issuer rule configuration. ActiveAccess enables issuers to deploy decoupled flows alongside standard challenge and frictionless authentication.

Validating Issuer Support

Issuer adoption of decoupled authentication has been progressing through 2024–2026, with major issuers in Europe and Asia-Pacific among the first to deploy. Before enabling decoupled flows in production, merchants and acquirers should check the ACS Information Indicator data element in card range responses to determine whether a given issuer’s ACS supports decoupled authentication. GPayments’ TestLabs provides a fully developed ACS environment for testing decoupled flows end-to-end before go-live.

Decoupled Authentication and the Regulatory Context

From a PSD2 SCA perspective, decoupled authentication can satisfy two-factor authentication requirements when the out-of-band challenge uses a qualified authentication factor — typically the cardholder’s biometric on their mobile device or a cryptographic approval from a registered device. The European Banking Authority’s Opinion on the review of PSD2 (EBA-Op-2022-06) and the Regulatory Technical Standards (RTS) on SCA confirm that out-of-band channel authentication is permissible, provided the authentication factors meet the independence and binding requirements.

For merchants and payment service providers in the EEA, decoupled authentication opens 3DS coverage to transaction types that were previously authenticated through inferior or non-standard mechanisms. It also provides a path to SCA compliance for merchant-initiated transaction scenarios that sit outside the standard recurring exemption framework.

Frequently Asked Questions

What is decoupled authentication in 3DS?

Decoupled authentication is a 3DS challenge flow where the authentication prompt is sent to the cardholder asynchronously — typically via a push notification to their banking app — rather than requiring a synchronous step-up during the payment session. The cardholder can complete authentication on a separate device or at a later time, within a defined timeout period. This enables 3DS authentication for IoT devices, kiosks, MOTO transactions, and other scenarios where a real-time in-session challenge is not feasible.

How is decoupled authentication different from a standard 3DS challenge?

A standard 3DS challenge is synchronous: the cardholder completes it during the payment session, and the merchant waits for the result before proceeding. Decoupled authentication is asynchronous: the challenge is delivered separately (on another device or at a later time), and the merchant receives the result when the cardholder completes it or when the timeout is reached. The EMV 3DS specification uses the transaction status value ‘D’ to indicate that decoupled authentication has been confirmed by the ACS.

Which version of EMV 3DS supports decoupled authentication?

Decoupled authentication was introduced in EMV 3DS version 2.2.0, published by EMVCo in 2018. Version 2.3 (released October 2021) and the subsequent 2.3.1.1 update (May 2023) significantly enhanced decoupled authentication with improved message structures, timeout mechanisms, and support for Secure Payment Confirmation. Both 2.2 and 2.3 support decoupled flows, but 2.3 provides the most complete implementation.

Does decoupled authentication provide liability shift?

When decoupled authentication produces a successful authentication result through a compliant 3DS flow, the liability shift mechanism applies in the same way as for standard challenge and frictionless flows. Card scheme rules (Visa Secure, Mastercard Identity Check) govern the specific conditions. A timed-out or incomplete decoupled authentication does not produce an authenticated result and does not trigger liability shift.

How do I implement decoupled authentication?

Implementation requires a 3DS Server that supports EMV 3DS 2.2 or later and can handle asynchronous authentication flows, including pending state management and timeout handling. On the issuer side, the ACS must support decoupled flows and have a mechanism to deliver out-of-band challenges (typically push notifications). Merchants should validate issuer ACS support for decoupled authentication before enabling the feature in production. GPayments’ ActiveServer (3DS Server) and ActiveAccess (ACS) both support decoupled authentication flows.

Is decoupled authentication available in Australia?

Decoupled authentication availability depends on issuer ACS capabilities and their support for EMV 3DS 2.2 or later. Major international card issuers are progressively deploying 3DS 2.3 support. Merchants and acquirers in Australia should work with their 3DS provider to assess current ACS support levels for decoupled flows before enabling the feature. GPayments’ TestLabs provides an environment where merchants can test decoupled authentication flows against fully developed ACS components.

Extending 3DS to the Transactions That Need It Most

Decoupled authentication extends the reach of EMV 3DS to payment environments that were previously outside the protocol’s scope — and with it, extends the security, liability shift, and regulatory compliance benefits of authenticated transactions to a broader set of use cases. The protocol infrastructure has been available since EMV 3DS 2.2, and 2.3 provides the most complete implementation.

For payment businesses evaluating decoupled authentication, the practical next step is to assess issuer ACS support for decoupled flows in your target markets, validate your 3DS Server’s asynchronous handling capabilities, and test end-to-end before enabling in production. The use cases are real, the protocol is defined, and issuer adoption is progressing — the question is whether your authentication infrastructure is ready to support them.

Ready to Implement Decoupled Authentication?

GPayments provides both sides of the decoupled authentication equation: ActiveServer (3DS Server) for merchants and acquirers, and ActiveAccess (ACS) for issuers. Both support EMV 3DS 2.2 and 2.3 decoupled flows. Test your implementation in our end-to-end TestLabs environment before going live.

Contact our team: gpayments.com/contact