If your frictionless rate is lower than your peers and your data quality looks fine, there is a good chance the problem sits earlier in the checkout than you have been looking. Before an authentication request is ever sent, the browser flow gives the issuer one opportunity to collect device information directly. That mechanism is the 3DS Method URL, and a surprising number of production integrations either skip it, fire it too late, or handle its timeout so badly that the data never arrives.
The consequence is not an error message. It is a quietly elevated challenge rate that nobody can account for.
What the 3DS Method URL actually does
The 3DS Method URL is a mechanism defined in the EMV 3D Secure protocol that lets the Access Control Server (ACS) gather detailed device and browser information during the checkout process, before authentication begins.
Mechanically it is simple. The 3DS Requestor loads a URL in a hidden iframe, which executes JavaScript to gather browser and device characteristics. The process runs asynchronously and is transparent to the cardholder, who sees nothing. The data collected goes to the ACS, and only to the ACS.
That last point is worth sitting with, because it explains the design. The 3DS Server facilitates the connection but does not receive the device data. The privacy model of the protocol depends on device-level information reaching the issuer without passing through the merchant or the acquiring side in readable form.
Why it exists at all, given the browser data already in the request
A reasonable objection is that the authentication request already carries browser information. For every browser-based transaction the 3DS Server populates a defined set of browser data, including accept headers, IP address, whether Java and JavaScript are enabled, language, screen colour depth, screen height and width, time zone, and user-agent.
So why the extra step?
Because that set is what the 3DS Server can observe from the request. The 3DS Method URL runs in the cardholder’s browser under the ACS’s own script, which gives the issuer a richer and more directly observed picture. It is the difference between being told about a device and looking at it.
For an issuer running risk-based authentication, that difference shows up directly in the decision. More confident device recognition means a returning cardholder on a known device is more likely to pass without a challenge.
The five-second constraint, and what happens when you hit it
EMVCo documents the timing explicitly. The 3DS Method process typically completes within five seconds. If it does not complete within that window, the process fails, but the merchant can still proceed with the Authentication Request.
This is a well-designed fallback and it is also where most implementations go wrong. Two failure patterns recur.
The first is treating the timeout as fatal. Teams build the checkout so that a failed 3DS Method blocks progression, and cardholders sit looking at a spinner. The specification is clear that you proceed with the authentication request regardless.
The second is the opposite problem. Teams fire the 3DS Method URL and immediately send the authentication request without waiting at all, so the outcome is always reported as incomplete. Technically compliant. Practically, it throws away the entire benefit.
The correct behaviour sits between the two. Fire early, wait for completion up to the window, then proceed either way and report honestly what happened using the completion indicator.
Fire it early, not at the payment button
Executing the 3DS Method URL early in the checkout process maximises the likelihood that the issuer has the information it needs before authentication.
In practice this means the mechanism should not be bolted onto the payment submit handler. By that point the cardholder has already clicked and is waiting, which turns the five-second window into five seconds of visible delay and makes a timeout far more likely to matter.
Better placements include the moment the cardholder reaches the payment step, or the moment card details are entered and the card range is known. Both give the process room to complete while the cardholder is still doing something else.
What you need in place before any of this works
The 3DS Method URL is not universally available. It is supplied through card range data from the Directory Server, alongside the protocol versions the ACS supports for that range and the message extensions it supports. The 3DS Method URL data element may be omitted where the ACS does not support it for a specific card range.
That has three practical implications.
Your card range data must be current. If your cache is stale, you may be working from a 3DS Method URL that no longer applies, or missing one that has since been added.
Your integration must handle absence cleanly. No 3DS Method URL for a range is a normal condition, not an error, and the flow should proceed without it.
And you need somewhere for the result to land. The 3DS Method Notification URL is sent in the initial request to the ACS and is the endpoint that receives notification of completion. If that endpoint is unreachable from the cardholder’s browser, nothing else in this article matters.
Reporting the outcome honestly
Two data elements carry the result into the authentication request. The 3DS Method Completion Indicator states whether the process completed. The 3DS Method ID contains the 3DS Server Transaction ID used during the execution, which is how the ACS links what it collected to the transaction now being authenticated.
Populate both accurately. Reporting completion for a process that timed out gives the issuer a reference it cannot resolve, and an ACS that cannot resolve the reference has less to work with than if you had simply told it the truth.
How to find out whether yours is working
Most teams have never checked. The diagnostic is straightforward and worth running this week.
Take a sample of recent browser-channel transactions and answer four questions. What proportion of card ranges in your traffic actually supply a 3DS Method URL? Of those, in what proportion did you execute it? Of those executions, what proportion completed inside the window? And does your challenge rate differ between completed and incomplete populations?
That last comparison is the one that turns this from a specification detail into a business case. If completion correlates with lower challenge rates across your own traffic, you have your own first-party evidence, which is considerably more persuasive internally than anything a vendor tells you.
Be careful reading it, though. Completion and challenge outcomes are both influenced by device, channel and cardholder history, so treat the comparison as a signal worth investigating rather than proof of a causal effect.
Where this sits in the wider picture
The 3DS Method URL is one input among several. It does not override issuer risk policy, and no amount of device data will carry a genuinely suspicious transaction through frictionlessly, nor should it. What it does is remove an avoidable information deficit.
Many of the frictionless-rate problems we see in acquiring-side implementations come down to the issuer being asked to make a decision with less than it could have had. This mechanism is one of the cheapest ways to close part of that gap, and unlike most authentication optimisation work it requires no change to issuer behaviour at all.
Frequently Asked Questions (FAQs)
What is the 3DS Method URL?
The 3DS Method URL is a mechanism within EMV 3-D Secure that allows the Access Control Server (ACS) to collect device and browser information before authentication begins. It typically runs through a hidden iframe and is transparent to the cardholder.
Why is the 3DS Method URL important for frictionless authentication?
The 3DS Method gives the issuer additional, directly observed device information that can support risk-based authentication. Better device recognition may help an issuer identify known devices and make a more informed decision about whether a transaction can proceed without a challenge.
How long should the 3DS Method take to complete?
The 3DS Method typically completes within five seconds. If it does not complete within that window, the authentication flow can still proceed rather than treating the timeout as a fatal error.
What happens if the 3DS Method URL is skipped?
Skipping the 3DS Method can leave the issuer with less device-level information when assessing the transaction. This information deficit can reduce the issuer’s ability to recognise a device confidently and may contribute to a higher challenge rate, although challenge outcomes also depend on other risk factors.
When should the 3DS Method URL be executed?
It should be initiated early enough in the checkout to give it time to complete without adding visible delay for the cardholder. The article suggests triggering it when the cardholder reaches the payment step or when the card range becomes known, rather than waiting until the payment button is clicked.
Is the 3DS Method URL available for every transaction?
No. The 3DS Method URL may be omitted when the ACS does not support it for a particular card range. Integrations should therefore handle its absence as a normal condition and allow the authentication flow to continue.
How can merchants check whether their 3DS Method implementation is working?
Teams can review browser-channel transactions to measure how often a 3DS Method URL is available, how often it is executed, how frequently it completes within the required window, and whether challenge rates differ between completed and incomplete populations. Any correlation should be treated as a signal for further investigation rather than proof of causation.
Reviewing your 3DS Server implementation?
ActiveServer is the GPayments 3DS Server solution for acquirers, gateways and payment service providers. Speak with a 3DS specialist about your browser-channel configuration.