How to Scope 3DS Regression Testing When a Component Changes

Changes arrive at a 3DS deployment from more directions than most test plans anticipate. A specification bulletin. A new device information version driven by an operating system release. A vendor patch. A scheme programme update. A counterparty moving to a different protocol version.

Two failure patterns follow. Some teams retest everything every time, which is expensive enough that it eventually stops happening. Others retest nothing until something breaks in production.

3DS regression testing works better when the scope is matched to the type of change. Here is a framework for doing that.

Start by knowing what you are on

You cannot scope a retest without an accurate picture of your own estate, and most organisations do not have one.

The reason is that EMV 3DS is not a single specification. There is a Core Specification, an SDK Specification, an SDK device information specification, a Split-SDK Specification and a set of message extensions, plus a long list of specification bulletins. They move independently, by design.

Your inventory should record, per component, which version of each relevant document it implements and which bulletins apply. A single version number in a vendor contract does not capture this, and a retest scoped against that single number will miss things.

The change types, and what each one demands

A new device information version. This is the recurring one. The device information update cycle is linked to operating system updates rather than the specification release cycle, and operating systems typically release at least one major version a year. So this trigger fires annually at minimum, whether or not you plan for it.

Scope: app-based flows end to end, device data population, and the handling of unavailable parameters. On the issuing side there is a specific obligation attached, because the ACS must return the highest data version number it supports, ACSs are urged to support all announced versions to help avoid step-up authentication, and EMVCo expects systems to be upgraded as quickly as possible after a release. Retest that your component reports the right version and behaves correctly against more than one.

A specification bulletin. Read it before scoping. Bulletins carry updates, clarifications, errata and key features, and some change behaviour that a plain reading of the base specification would not reveal. Scope to the areas the bulletin actually touches, which is usually narrow.

A protocol version change, yours or a counterparty’s. The broadest trigger. Beyond the features themselves, test version tolerance: in version 2.2.0 the protocol version elements are constrained only by data type and length, so a Directory Server may report a higher version and your 3DS Server must not respond in error.

A vendor release. Scope by the release notes, and then add a standing core set, because vendor notes describe what changed rather than what it affected.

A message extension change. Extensions can be released or updated independently of specification releases. Scope to the extension, the components in its path, and the degradation case where a component does not support it.

A scheme programme change. Scope per scheme. Behaviours that differ between schemes must be tested per scheme, not once.

The core set that runs every time

Whatever the trigger, a small set is cheap enough to run always and catches most cross-cutting breakage.

One frictionless transaction and one challenged transaction per channel you support. One out-of-band challenge per channel. One interruption scenario, ideally a browser reload mid-challenge. One capability-discovery check confirming card range data is current and being read. And one negative case confirming your components still handle an unrecognised value correctly.

That set takes hours rather than weeks, and it turns the question from whether to retest into how much.

A standing item most teams miss

One rule with a quiet maintenance cost attached: the latest version of each referenced ISO standard applies, including published amendments, unless a publication date is specified, and version 2.3.1 states this explicitly.

Several data elements depend on those standards, including country and state encoding. A standard revision is therefore a change to your implementation’s correct behaviour without any 3DS document changing at all. Worth a periodic check rather than a trigger you will be notified about.

Building the matrix

Put change types down one axis and test areas across the other, then mark each cell as full, partial or not required, with a reason.

The reason column is the valuable part. It is what lets a future engineer trust the matrix rather than quietly expanding scope out of caution, which is how organisations end up back at retesting everything.

Review the matrix when something reaches production that the matrix said did not need testing. That is the only reliable signal that a cell is wrong, and treating each such incident as a matrix update rather than a one-off fix is what makes the framework improve over time.

Where testing should be deliberately generous

Two areas justify more scope than the change type strictly implies.

Anything invisible. Mechanisms designed to be hidden from the cardholder produce no complaints when they break. EMVCo’s own recommendation on the browser data collection mechanism is that the requestor and ACS perform extensive testing to ensure execution remains hidden and transparent. Apply the same logic anywhere failure is silent.

Anything platform-dependent. Where behaviour depends on an operating system rather than on the specification, the specification cannot protect you. Autofill is the clearest example, where EMVCo strongly recommends ACSs test on iOS before offering it and notes other platforms may have similar heuristics. Platform-dependent behaviour should be retested on platform changes, not only on 3DS changes.

Frequently Asked Questions

How often will a device information change force a retest?

At least annually. The device information update cycle is tied to operating system updates rather than the specification release cycle, and operating systems typically release at least one major version each year. Plan a recurring slot rather than treating each as an incident.

Do we need to retest when a counterparty changes version?

Test version tolerance rather than their features. In version 2.2.0 the protocol version elements are constrained only by data type and length, so a Directory Server may report a higher version, and your 3DS Server must not respond in error. That behaviour is worth confirming explicitly.

Can we scope a retest from the specification version alone?

No. EMV 3DS is a family of documents that move independently, plus a long list of bulletins. An accurate inventory records which version of each relevant document every component implements and which bulletins apply, and the retest is scoped against that.

What should run on every change regardless?

A frictionless and a challenged transaction per channel, an out-of-band challenge per channel, one interruption scenario, a capability-discovery check, and one negative case. It takes hours and catches most cross-cutting breakage.

Planning a 3DS test strategy? TestLabs is the GPayments 3DS testing environment. Speak with a 3DS specialist about regression scope.