What happens to 3DS when JavaScript is disabled or unavailable
A small proportion of your browser traffic runs with JavaScript disabled, and 3DS behaves differently there. Privacy configurations, corporate builds, assistive setups, older embedded browsers, and a certain amount of automated traffic you would rather not serve anyway.
For most of your checkout, a JavaScript disabled browser is a rendering problem. For 3D Secure it is something more specific, because part of the authentication data the issuer wants can only be gathered by executing script in the browser, and part of the challenge flow assumes the browser can post a form on its own.
Both have defined answers in the specification. Neither is widely implemented well.
Which data you lose
The browser information sent in the authentication request consists of five elements: whether Java is enabled, screen colour depth, screen height, screen width, and time zone.
The 3DS Server can obtain that data only if JavaScript is enabled.
So where script does not run, those five elements are unavailable. Everything else in the browser data set, including accept headers, IP address, language and user agent, comes from the request itself rather than from script and is unaffected.
The handling of the missing elements depends on the protocol version and the component involved, and EMVCo has published a separate document, the AReq Browser Data Elements Recommendations, specifically to cover it. That document is where your implementation guidance should come from rather than local invention.
The practical point for anyone planning: this is a defined condition with published handling, not an edge case you are expected to improvise around.
The fallback the specification requires
The second half of the problem is the challenge itself, and here the requirement is explicit rather than advisory.
The browser-based requirements include a step whose fallback method means the implementation must support an alternative approach for environments that do not support JavaScript. EMVCo describes what that can look like: some form of HTTP post that may require consumer participation, such as clicking a button. The example given is providing the consumer with a button to enable a submit where JavaScript is not supported.
In other words, where the flow would normally auto-post a form, a non-script environment needs a visible control that the cardholder presses to achieve the same thing.
This is a requirement on the implementation, not an optional enhancement. A checkout that silently stalls for a non-script browser is not conforming, and the failure is invisible in your analytics because the transaction never reaches a state that gets reported.
Why this is worth testing even at low volume
Three reasons it deserves more attention than its traffic share suggests.
The failure is silent. A cardholder in a non-script environment does not see an error. They see a page that stops doing anything. Nothing in your funnel reporting distinguishes that from ordinary abandonment.
The population is not random. Corporate and institutional environments disproportionately restrict scripting, and those are often higher-value cardholders. A failure concentrated in that segment costs more per transaction than the volume implies.
It is a conformance requirement. The fallback is part of the browser-based requirements. Whether you ever see the traffic or not, an implementation that cannot handle it does not meet the specification.
What to check in your own implementation
Four questions, all answerable in an afternoon.
Does your checkout render a usable challenge when scripting is disabled, and can a cardholder complete it? Test with script genuinely disabled rather than mocked.
When the five script-dependent browser elements are unavailable, does your 3DS Server handle their absence according to the published recommendations for your protocol version, or does it substitute defaults? Substituting defaults is the failure mode discussed below.
Do you have any visibility at all into how many authentication attempts start in a non-script environment? Most implementations cannot answer this.
Does your challenge iframe configuration still work in that environment? The iframe requirements are a separate topic but they interact here.
The thing not to do
Do not fill the missing elements with plausible defaults.
It is tempting. You know most screens are a particular size, most browsers report a particular colour depth, and the transaction will validate if the fields are populated. It will also be wrong, and the ACS will treat the values as assertions about the device.
The wider principle applies here as everywhere in 3DS: incomplete or incorrect information, including values that do not accurately represent the cardholder or the transaction context, can lead to increased challenges or declined authentication. Fabricating five device attributes for a population of cardholders whose real attributes you cannot see is precisely the pattern that trains an issuer’s risk model against you.
Follow the published recommendations for absent elements instead. They exist for this.
Frequently Asked Questions
Which browser elements cannot be collected without JavaScript?
Five: Java enabled, screen colour depth, screen height, screen width and time zone. The 3DS Server can obtain these only where JavaScript is enabled. The remaining browser elements derive from the request rather than from script.
Is supporting a non-script fallback optional?
No. The browser-based requirements state that the implementation must support an alternative approach for environments that do not support JavaScript. EMVCo gives the example of an HTTP post requiring consumer participation, such as a button the cardholder clicks to submit.
Should we substitute default values for the missing elements?
No. Handling for absent elements depends on the protocol version and component and is set out in EMVCo’s AReq Browser Data Elements Recommendations. Fabricated values are assertions about the device, and inaccurate information can increase challenges or cause declined authentication.
Does this affect app-based transactions?
No. This is specific to the browser channel. App-based flows collect device data natively through the SDK, which does not depend on browser scripting.
Reviewing your browser-channel implementation? ActiveServer is the GPayments 3DS Server solution for acquirers, gateways and payment service providers. Speak with a 3DS specialist about browser flow handling.
