Out-of-band authentication in a native app should be the smoothest experience in the whole protocol. The cardholder is already on their phone, the banking app is already installed, and the approval is one biometric prompt away.
When it works, it is exactly that. When it fails, it fails in a way that produces no error the cardholder can act on, and a support ticket that says the payment just stopped.
The failures are well documented, and they are almost entirely about app switching.
Three patterns, not one
The specification supports three distinct app-channel out-of-band arrangements, and teams frequently talk about them as though they were one thing.
Manual switching. The cardholder is instructed to leave the merchant app, open their authentication app, approve, and come back themselves. This works everywhere and depends entirely on the cardholder completing a multi-step journey unprompted.
Automatic switching to the 3DS Requestor App. Available from version 2.2 of the specification onwards. During the challenge, the ACS instructs the cardholder to switch manually from the checkout to the out-of-band authentication app. Once they have authenticated, the authentication app automatically returns them to the challenge screen in the merchant app, assuming both apps are on the same device. The cardholder makes one deliberate move rather than two.
Automatic switching to the out-of-band app. Introduced with version 2.3.1 data elements, this automates the outbound leg as well, taking the cardholder into the authentication app rather than asking them to find it.
The direction of travel across versions is clear. Each revision removes another manual step, because each manual step is a place the cardholder drops out.
Which patterns you can use depends on the protocol version in play, which in turn depends on what the ACS supports for the card range. This is not a single choice you make once for your whole estate.
The precondition that is easy to overlook
Automatic switching only works where the ACS has defined, deployed and communicated an out-of-band authentication process to the cardholder.
That word communicated is doing real work. A cardholder who has never been told that their banking app can approve payments will not recognise what is happening when their phone switches apps mid-checkout. Some proportion will assume something has gone wrong and back out.
Automatic switching is a technical capability sitting on top of a cardholder-education dependency. Issuers that enable the first without investing in the second tend to see less benefit than expected, and conclude the feature does not work.
Where it breaks
EMVCo documents specific technical variants for the automatic switching flows, and they are the cases worth building for because they are the ones that produce silent failure.
The operating system cannot match the app URL to an installed app. The flow depends on handing the device a URL that resolves to a specific application. If the target app is not installed, has been uninstalled, or the association between URL and app has not been registered correctly, the switch does not happen. Nothing crashes. The cardholder is simply left where they were.
The app URL is invalid, or the device runs a custom operating system. The URL may be malformed, or the device may run a variant operating system that handles app association differently from the mainstream implementations the integration was tested against. This is more common than teams expect in markets where non-standard Android distributions have meaningful share.
Both variants apply to both directions of switching, and both produce the same symptom from the cardholder’s point of view, which is nothing happening.
Why this is worse than an error
A failed authentication produces a result. A failed app switch produces a cardholder staring at a screen.
From the issuer’s side, the transaction is sitting waiting for a challenge that will never be completed, and will eventually time out. From the merchant’s side, the checkout is in a challenge state with no resolution. From the cardholder’s side, the payment appears to have frozen.
None of those three parties has information that would let them diagnose it in the moment, which is why these cases tend to surface as unexplained drop-off in a funnel report weeks later rather than as an incident.
Building for the failure rather than the happy path
Four things separate implementations that handle this well from ones that do not.
Always have a manual fallback path. If the automatic switch does not occur, the cardholder needs a visible instruction telling them what to do. This is the single highest-value mitigation, and it costs almost nothing. The same principle EMVCo applies to browser-channel out-of-band, where it recommends prompting the cardholder to switch manually if a push notification does not arrive, applies here.
Show the cardholder that time is passing. A countdown makes it clear the process is unfinished and gives the cardholder a reason to act. Silence reads as completion.
Register your app associations properly and verify them. URL-to-app association is the mechanism the whole automatic flow rests on. It is configuration that is easy to get wrong, easy to break during a release, and rarely tested after the first integration.
Test on the devices your cardholders actually use. Testing on two flagship handsets tells you little about the custom operating system variants that may carry real share in your markets. If a meaningful portion of your base runs something other than mainstream Android or iOS, that population needs explicit coverage.
How to detect whether this is affecting you
The pattern is distinctive once you know to look for it.
Segment your app-channel out-of-band challenges by outcome and look for challenges that were initiated and then never resolved, as distinct from challenges the cardholder actively abandoned or failed. A population that starts and never returns, concentrated on particular device or operating system profiles, is the signature.
If your logging does not currently distinguish between a challenge that was abandoned and one that timed out without the cardholder ever reaching the authentication app, that is worth fixing before anything else. You cannot tune what you cannot see, and this failure mode is invisible in aggregate challenge-completion figures.
The relationship to the browser channel
This article covers the app channel. Browser-channel out-of-band has its own, different failure mode, centred on the cardholder needing to return to a checkout page and press a completion button. The underlying theme is the same in both channels, which is that any step depending on the cardholder navigating between contexts is a step where transactions are lost, and the protocol has been steadily removing those steps version by version.
If you support both channels, the two need separate analysis. The mitigations do not transfer.
Frequently Asked Questions
What happens if the ACS sends an app URL but no label for it?
The SDK must not return an error message, and the absence does not end the flow. What happens instead is that the SDK does not display the button in the user interface, because there is no label for it, and the cardholder has to switch manually. The feature silently degrades to the manual pattern, which is exactly the kind of failure that never appears in an error log.
What URL format should we use?
Universal and app links, as defined in version 2.3.1, are strongly recommended. Version 2.2.0 defines the requestor app URL as a fully qualified URL, but newer Android and iOS versions have changed how these URLs and their security work, which is why the platform-specific link mechanisms are now the recommended route.
Does the cardholder still have to tap a completion button?
Not in the version 2.2.0 native flow. EMVCo notes that the automatic challenge request functionality directs the cardholder to the requestor confirmation page as soon as the requestor app is brought to the foreground, which removes the manual completion step that causes drop-off elsewhere.
Should the ACS expect a transaction ID inside the requestor app URL?
No. Although the definition mentions that each transaction would require a unique transaction ID using the SDK transaction ID, this is not mandated, and the ACS should not depend on its presence. The SDK transaction ID is present in each challenge request as a separate data element.
Integrating app-based authentication? ActiveSDK is the GPayments mobile 3DS SDK. Speak with a 3DS specialist about app-channel out-of-band flows.