What Decoupled Authentication Means<\/h2>\n
In a standard EMV 3DS 2.x challenge flow, the authentication challenge is synchronous<\/a>: the cardholder is presented with a step-up prompt \u2014 an OTP, biometric verification, or push approval \u2014 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\u2019s 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 \u2014 seven days \u2014 via the threeDSRequestorDecMaxTime parameter in the EMV 3DS specification).<\/p>\n The flow works as follows: the 3DS Server initiates a decoupled authentication request; the issuer\u2019s ACS evaluates the transaction and confirms decoupled authentication via the ACS Decoupled Confirmation Indicator (transaction status \u201cD\u201d); 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 \u2014 or a timeout is returned if the cardholder does not respond within the configured period.<\/p>\n Mail order\/telephone order (MOTO) transactions<\/a> 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 \u2014 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\u2019s registered mobile device for approval, bringing 3DS coverage (and liability shift) to a transaction type that was previously outside the protocol\u2019s reach.<\/p>\n 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\u2019s white paper specifically identifies subscription-based merchants confirming account validity as a core decoupled authentication scenario.<\/p>\n 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\u2019s registered mobile device. This extends 3DS authentication \u2014 and its associated liability shift \u2014 to unattended payment environments where the device itself has no authentication interface.<\/p>\n 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.<\/p>\n 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 \u2014 maintaining the transaction context during the period between the decoupled request and the authentication result \u2014 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.<\/p>\n GPayments\u2019 ActiveServer<\/a> 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.\u00a0<\/p>\n On the issuer side, the ACS must support decoupled authentication flows and have a mechanism to deliver out-of-band challenges to cardholders \u2014 typically via push notification to the issuer\u2019s 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.<\/p>\n GPayments\u2019 ActiveAccess<\/a> 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.<\/p>\n Issuer adoption of decoupled authentication has been progressing through 2024\u20132026, 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\u2019s ACS supports decoupled authentication. GPayments\u2019 TestLabs<\/a> provides a fully developed ACS environment for testing decoupled flows end-to-end before go-live.\u00a0<\/p>\n From a PSD2 SCA perspective, decoupled authentication can satisfy two-factor authentication requirements when the out-of-band challenge uses a qualified authentication factor \u2014 typically the cardholder\u2019s biometric on their mobile device or a cryptographic approval from a registered device. The European Banking Authority\u2019s<\/a> Opinion on the review of PSD2<\/a> (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.\u00a0<\/p>\n 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.<\/p>\n Decoupled authentication is a 3DS challenge flow where the authentication prompt is sent to the cardholder asynchronously \u2014 typically via a push notification to their banking app \u2014 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019 ActiveServer (3DS Server) and ActiveAccess (ACS) both support decoupled authentication flows.<\/p>\n 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\u2019 TestLabs provides an environment where merchants can test decoupled authentication flows against fully developed ACS components.<\/p>\n Decoupled authentication extends the reach of EMV 3DS to payment environments that were previously outside the protocol\u2019s scope \u2014 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.<\/p>\n 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\u2019s 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 \u2014 the question is whether your authentication infrastructure is ready to support them.<\/p>\nKey Use Cases for Decoupled Authentication<\/h2>\n
MOTO and Subscription Payments<\/h3>\n
Unattended Payment Terminals and Kiosks<\/h3>\n
Emerging IoT and Connected Device Scenarios<\/h3>\n
![\"Decoupled](\"https:\/\/www.gpayments.com\/blog\/wp-content\/uploads\/2026\/05\/Gemini_Generated_Image_9kpvah9kpvah9kpv-300x164.png\")
<\/p>\nImplementation Considerations<\/h2>\n
3DS Server Requirements<\/h3>\n
ACS Requirements<\/h3>\n
Validating Issuer Support<\/h3>\n
Decoupled Authentication and the Regulatory Context<\/h2>\n
Frequently Asked Questions<\/h2>\n
What is decoupled authentication in 3DS?<\/h3>\n
How is decoupled authentication different from a standard 3DS challenge?<\/h3>\n
Which version of EMV 3DS supports decoupled authentication?<\/h3>\n
Does decoupled authentication provide liability shift?<\/h3>\n
How do I implement decoupled authentication?<\/h3>\n
Is decoupled authentication available in Australia?<\/h3>\n
Extending 3DS to the Transactions That Need It Most<\/h2>\n