How to Build 3DS Negative Testing Into Your Test Plan

Certification proves your implementation can complete a transaction correctly. It is not designed to prove your implementation behaves sensibly when something goes wrong, and something goes wrong far more often than anyone plans for.

3DS negative testing is the part of the test plan that covers everything after the happy path. It is usually the part that gets cut when a go-live date moves, and it is the reliable predictor of how bad the first month in production will be.

Here is a matrix worth building.

Interruption scenarios

The most valuable category, because these are the failures that produce no error anywhere.

Browser reload during a challenge. The cardholder refreshes, the connection drops, or the operating system reclaims the tab. Your requestor must be able to restore the challenge iframe, refresh the payment page, and post the same challenge request again. Test that it does, because EMVCo’s recommendation is that the requestor shall always restore the iframe in this case, and an implementation that cannot recreate it turns a recoverable interruption into a lost sale.

Repeated challenge requests. The ACS side of the same scenario. Multiple challenge requests may be sent to recover from an error with the cardholder. An ACS can reject a repeat as a duplicate, but it also has the option to accept it where the subsequent request is identical to the original, and can then either restart the challenge or continue from the last exchange. For mobile browser transactions, ACSs shall accept multiple challenge requests. Test all three behaviours: duplicate rejection, restart and continuation.

The loop condition. Where a challenge request keeps arriving after an out-of-band authentication that was never completed, the ACS must detect that it is looping and exit. This is the test almost nobody writes, and it is the one that produces a runaway incident.

App switching failures. Where automatic switching depends on the device resolving an app URL, test the cases where the operating system cannot match the URL to an installed app and where the URL is invalid or the device runs a variant operating system.

Timeout scenarios

Browser data collection timeout. The pre-authentication mechanism typically completes within five seconds. Where it does not, the process fails but the merchant can still proceed with the authentication request. Test both branches, and specifically test that a failure does not block the checkout.

Out-of-band challenge timeout. Verify what your components do when the cardholder never returns.

Component unavailability. What happens when a downstream component does not respond at all, as distinct from responding with an error.

Data and message scenarios

Empty versus absent fields. These produce different errors. An empty optional field returns an invalid-format error, while an empty JSON object containing mandatory data may return a missing-element error. Test that your components distinguish them.

Unrecognised capability values. Where a preparation response contains an indicator value undefined for the protocol version, 3DS Servers must respond with an error message. Test that yours does.

Values outside the accepted set. On older versions, devices can return screen colour depth values the specification does not list, and the handling is to supply the closest lower listed value rather than error. Test it with a value the specification does not contain.

Encoding tolerance. Where received content is not strictly valid but can be recovered and decrypted, the guidance in several cases is to proceed rather than reject. Test that your components are tolerant where tolerance is correct, not just strict where strictness is correct.

Non-script environments. The browser-based requirements include a fallback for environments that do not support JavaScript. Test with scripting genuinely disabled rather than mocked.

Version and platform scenarios

Mixed-version interactions. In version 2.2.0, protocol version elements are constrained only by data type and length, so a Directory Server may report a higher version, and 3DS Servers must not respond in error. Test that yours does not.

Cross-version SDK behaviour. A Split-SDK certified to a later version may operate in an earlier-version environment, behaving as an earlier-version default SDK from the ACS point of view, with the earlier UI requirements and message formats supported. If that applies to your estate, test it explicitly.

Device information versions. ACSs are expected to support all announced data version numbers, and are urged to do so to help avoid step-up authentication. Test against more than the newest.

Platform autofill. Version 2.3.1.1 supports autofill, and on iOS the heuristics can fill both entries on a two-field screen regardless of the declared type, or suggest credentials irrelevant to the challenge. EMVCo strongly recommends ACSs test autofill on iOS before offering it, and notes other platforms may behave similarly.

Rendering scenarios

Required UI elements. The ACS must supply every required UI element for the template it selects, or the SDK aborts the challenge and returns a missing mandatory element error. Test each template with a deliberately incomplete set to confirm the failure is visible to you rather than only to the cardholder.

Oversized content. The SDK supports scrolling where the interface exceeds the screen. Test with content that overflows, and confirm the header stays anchored and the cancel control remains reachable.

Missing optional labels. Where the ACS supplies an out-of-band app URL without its label, the SDK must not return an error. It simply does not display the button, and the cardholder must switch manually. Test that this degrades rather than fails.

How to prioritise

You will not build all of this at once. Rank by two questions: how likely is the scenario in your traffic, and how visible is the failure if it occurs.

Scenarios that are invisible when they fail come first, regardless of likelihood, because you will not detect them in production. Interruption and rendering scenarios dominate that group. Scenarios that fail loudly can wait, because your monitoring will find them.

And test the hidden mechanisms specifically. EMVCo’s recommendation on the browser data collection mechanism is that the requestor and ACS perform extensive testing to ensure its execution remains hidden and transparent to the cardholder, because a mechanism designed to be invisible is one nobody will report as broken.

Frequently Asked Questions

Does certification testing not cover this?

Certification demonstrates that an implementation conforms and can complete transactions correctly. Negative paths, interruption handling and platform-specific behaviour largely sit outside it. The two are complementary rather than overlapping.

What is the single most valuable negative test?

Browser reload during a challenge. EMVCo’s guidance is that the requestor shall always restore the challenge iframe and post the same challenge request again, and an implementation that cannot do this converts a recoverable interruption into a lost transaction with no error recorded anywhere.

Should the ACS reject a duplicate challenge request?

Not necessarily. It may reject it as a duplicate, but it also has the option to accept a subsequent identical request and either restart the challenge or continue from the last exchange. For mobile browser transactions, ACSs shall accept multiple challenge requests. Test all the behaviours your platform supports.

Why test autofill specifically?

Because platform heuristics can override your intent. On iOS the autofill logic may fill both entries on a two-field screen regardless of the declared data entry type, or suggest credentials unrelated to the challenge. EMVCo strongly recommends testing on iOS before offering it, and notes other platforms may have similar behaviour.

Building a 3DS test plan? TestLabs is the GPayments 3DS testing environment. Speak with a 3DS specialist about negative path coverage.