Why Browser-Based Out-of-Band Authentication Fails on Mobile
Out-of-band authentication is meant to be the good option. The cardholder approves a payment in their banking app, where they are already enrolled, already recognised, and already familiar with the interface. No codes to read off an SMS, nothing to mistype.
It works well in app-based flows. In browser flows on a mobile device, it works considerably less well, and the failure mode is unhelpfully quiet. Issuers see authentication responses indicating the transaction timed out. Merchants sometimes see nothing at all, unaware that the cardholder finished the challenge successfully.
EMVCo has documented this and published recommendations in response. If your organisation supports browser OOB and has not reviewed the flow recently, this is worth an hour of somebody’s time.
How the browser OOB flow is usually built
When the issuer decides a transaction needs a challenge, the merchant opens an iframe on its checkout page and redirects to the issuer. The issuer supplies the user interface inside that iframe and instructs the cardholder to switch manually to their out-of-band authentication application, which may be a mobile app or a browser-based application, on the same device or a different one.
The cardholder switches, authenticates, and then has to switch back to the checkout page and press a Complete button.
That final step is the problem.
Where it breaks
Some merchants and issuers have reported lower success rates for out-of-band authentication when it is initiated from a mobile browser. The symptom appears in two forms. Either the issuer sends a declined authentication response indicating a timeout, or the merchant remains unaware that the cardholder completed the challenge.
EMVCo identifies the primary cause specifically. It arises when the cardholder is engaging with the merchant in a mobile browser and uses a mobile app on the same device for the out-of-band authentication.
Think about what that involves for the cardholder. They are in a browser. They leave it for a banking app. They authenticate. They now have to find their way back to a browser tab they may have lost track of, and press a button they have no particular reason to expect. From their point of view, they already approved the payment. The job felt finished.
That is the visible half of the problem. The mechanical half is more interesting, and EMVCo has documented it.
What is actually happening on the device
The issue has been identified as relating to application and memory management by the device operating system, on both Android and iOS.
The sequence runs like this. The cardholder switches from the mobile browser to the authentication app. The operating system puts the browser into the background and brings the authentication app to the foreground. Where available memory is limited, the operating system instructs background applications to free up memory, or in the worst case kills them. The browser responds by deactivating tabs.
When the cardholder returns, the browser reactivates the tab they were on, but the reactivation behaves essentially as a page refresh. If the merchant has not received the authentication result in the meantime, the checkout page reloads, the challenge iframe is reopened, and a new challenge request is posted to the ACS to restore the challenge context. Depending on how the ACS handles the challenge and the receipt of multiple challenge requests, it may return a failed authentication result, an error message, or the transaction may simply time out.
Two consequences follow that change how you should think about this.
The first is that the cardholder can do everything right and the transaction can still fail. They authenticated. They came back. The tab did not survive.
The second is that this is not purely a low-end device problem. EMVCo notes that feedback from major operating system providers indicates lower-end devices with limited memory and processing power contribute to the issue, but that higher-end devices are not immune. Memory management depends on device memory, how many applications are open, and the operating system’s ability to save and restore application context, which means the failure is not reliably predictable.
The same scenario is theoretically possible for a transaction initiated from a merchant app rather than a browser, but it is unlikely, because an app has a smaller memory footprint than a browser.
The flow EMVCo recommends instead
The specification also permits an alternative browser-based flow, in which the issuer accesses the result of the out-of-band authentication directly and sends it to the merchant before the cardholder switches back to the checkout page.
EMVCo recommends this approach, because it removes the dependency on the cardholder pressing Complete and therefore avoids the cardholder inadvertently missing that final step and the transaction subsequently timing out.
The difference is structural rather than cosmetic. In the common flow, the authentication result reaches the merchant because the cardholder took an action. In the recommended flow, it reaches the merchant because the authentication happened. One of those is reliable.
This is the central decision for any issuer running browser OOB today. If your ACS supports the alternative flow, there is a strong case for using it. If it does not, that is worth raising with your provider, because it is the difference between a challenge method that works on mobile and one that leaks completions.
The five things EMVCo recommends
Not every organisation can switch flows this quarter. EMVCo has published a set of recommendations intended to harmonise merchant, 3DS Server and ACS implementations, and they divide cleanly by who has to act.
For the 3DS Server. Share the authentication status from the results message with the merchant as soon as it is received, and push that information to the merchant rather than requiring the merchant to retrieve it. Speed matters here, because the whole failure turns on whether the merchant learns the outcome before the cardholder returns.
For the merchant. On a browser restart, always restore the challenge iframe so the ACS can send the final challenge response. Refresh the payment page, reopen the iframe in the checkout page, and post the same challenge request as the original one.
For the ACS, on completion. Verify completion of the out-of-band authentication directly from the authentication server and send the results message immediately when the authentication completes. Do not wait for the cardholder to confirm through browser interaction, because the challenge window is lost when the browser is put to sleep or closed by the operating system, and waiting produces a timeout when cardholder interaction is no longer possible.
For the ACS, on repeat requests. Accept multiple challenge requests for a mobile browser-based transaction. Verify the consistency of the IP address, session data and message content before continuing, and check the out-of-band authentication status before acting. If the authentication completed, confirm completion with the cardholder and send the final challenge response. If it did not, restart the authentication. One caution attaches to this: where a challenge request arrives more than once after an authentication attempt, the ACS must ensure it is not looping between an uncompleted authentication and a fresh request, and exit if necessary. Where a challenge request arrives after the results message, the ACS should accept it rather than returning an error, confirm completion, and send the final response.
For the issuer. Keep the out-of-band authentication app small. Heavy applications increase the likelihood that the operating system requires the browser to free resources, which is the mechanism that starts the whole failure.
Alongside these, EMVCo has updated its technical FAQ with two interface measures that are cheap to implement. A countdown timer showing the cardholder how long remains communicates that the process is unfinished, which is the core misunderstanding. And a fallback prompt suggesting the cardholder switch manually to their authentication app addresses the case where a push notification does not arrive.
Note where the weight sits. Four of the five structural recommendations are about not depending on the cardholder’s return journey. The interface measures help; they do not fix the mechanism.
This is not only an issuer problem
It is tempting to file this under ACS configuration and move on. That would be a mistake, because the merchant side of the flow matters too.
How the iframe is presented, whether the checkout page survives being backgrounded, and how clearly the page communicates that authentication is still in progress all affect whether the cardholder returns. A checkout that looks finished when the cardholder switches back will not prompt anyone to press Complete.
EMVCo developed its recommendations in collaboration with the merchant and issuer community, and the working group has said it is also sharing feedback with web browser providers to explore how the browser itself could better support successful completion of the challenge. That is an acknowledgement that the problem sits across several parties rather than inside any one of them.
For now, the parties who can act are the issuer choosing the flow and the merchant building the page around it.
A short diagnostic
If you want to know whether this is costing you, look at the following in your own data rather than reasoning from first principles.
Separate your out-of-band challenges by channel, app-based against browser-based. Within the browser population, separate mobile from desktop where you can identify it. Then compare completion rates across those groups.
If mobile browser OOB completions sit materially below the others, and your declines in that population skew towards timeout outcomes, you are looking at the pattern EMVCo describes. The next question is simply whether your ACS supports the alternative flow.
Treat the numbers as an indicator rather than a proof. Channel mix correlates with merchant type, transaction value and cardholder demographics, all of which independently affect completion. The pattern is worth acting on; the attribution needs care.
The wider point about challenge method choice
Out-of-band authentication remains one of the better challenge methods available. It avoids the phishing exposure of passcodes sent by SMS, it uses an authenticator the cardholder already trusts, and it can carry richer context about what is being approved.
None of that helps if the result does not reach the merchant. Challenge method selection is not only a question of which method is most secure or most familiar. It is also a question of which method completes reliably in the channel the cardholder is actually using, and that answer differs between a desktop browser, a mobile browser and a native app.
Issuers that treat channel as a first-class input to challenge configuration, rather than applying one method everywhere, tend to end up with both better security and fewer abandoned payments.
Frequently Asked Questions (FAQs)
What is browser-based out-of-band authentication?
It is a 3D Secure flow where the cardholder starts in a browser, authenticates through a separate app, and then returns to the checkout.
Why can OOB authentication fail on mobile browsers?
Switching to an authentication app can cause the browser tab to reload or lose the challenge context, resulting in a timeout.
Can OOB authentication fail after successful approval?
Yes. The cardholder may authenticate successfully, but the transaction can still fail if the result does not reach the merchant.
What does EMVCo recommend for browser-based OOB authentication?
EMVCo recommends a flow where the issuer sends the authentication result to the merchant without relying on the cardholder to return and press Complete.
How should an ACS handle repeat challenge requests?
The ACS should accept repeat requests, verify their consistency and check whether OOB authentication has already completed.
How can issuers identify OOB timeout problems?
Compare OOB completion and timeout rates across app-based, mobile-browser and desktop-browser transactions.
Reviewing your challenge configuration?
ActiveAccess is the GPayments Access Control Server solution for issuers and processing centres. Speak with a 3DS specialist about out-of-band flows and challenge method selection.
