No payments estate upgrades in a single step. Some components move to a new protocol version quickly, others are constrained by vendor release cycles, scheme certification windows or simply by the fact that they work and nobody wants to touch them. The result is a period, often measured in years rather than months, where different parts of the same flow speak different versions.
The bridging message extension exists for exactly that period. It is one of the more useful mechanisms in the protocol and one of the least discussed outside implementation teams.
What it does
EMVCo published the bridging message extension in 2022 to enable version 2.1.0 and 2.2.0 products to use selected features introduced in version 2.3.1.0. It was subsequently updated to align with version 2.3.1.1.
The word doing the work in that sentence is selected. This is not a compatibility shim that makes an older product behave like a newer one. It is a defined extension that carries specific newer capabilities across the version boundary, and the set is deliberately limited.
A concrete example
The clearest illustration sits in exemption handling.
The Transaction Challenge Exemption element, which is how an Access Control Server reports which exemption it actually applied, is available natively in version 2.3.1. On version 2.2, it depends on the bridging message extension.
Consider what that means operationally. An acquirer running 2.2 components without the bridging extension can request exemptions, and issuers can grant them, but the acquirer has materially less visibility into what the issuer actually did. You can count what you asked for. You cannot reliably count what you received.
That undermines the entire feedback loop. Exemption strategy improves by comparing requests against outcomes and adjusting. Without the outcome signal you are tuning blind, and the most likely response to poor results is to stop requesting exemptions rather than to fix the requests, which is the wrong conclusion drawn from missing data.
For an organisation in that position, the bridging extension is not a nice-to-have. It is what makes the exemption reporting in the previous article possible.
Why an extension rather than an upgrade
The obvious question is why anyone would use this instead of simply moving to the current version.
Several reasons, all of them ordinary.
Version migration touches every component in the path and each one has its own dependency chain, vendor timeline and certification requirement. Moving the 3DS Server is not the same project as moving the ACS, and neither is the same as moving a mobile SDK across two app stores.
Counterparties move on their own schedules. Your version choice does not determine what the issuers you route to are running, nor what your merchants have integrated against.
And the business case for a full migration is usually driven by a small number of features. If two of those features are available through an extension, the case for the larger project weakens, or at least becomes less urgent.
The bridging extension lets an organisation capture part of the value now and sequence the migration properly, rather than treating it as all or nothing.
What it does not solve
This is where honest framing matters, because the extension is easy to oversell.
It covers selected features. Anything outside that set remains unavailable until the underlying components move. Before building a plan around it, establish exactly which capabilities you need and whether they are in scope, rather than assuming the extension closes your whole gap.
It requires support along the path. Like every message extension, it only functions where the components that need to process it actually support it. Supported message extensions are carried in card range data alongside the ACS protocol versions for a range, which is how the acquiring side can determine whether an extension will be honoured for a given issuer. An extension your 3DS Server supports and the receiving ACS does not is not a working capability.
And it does not remove the migration. Running on an older version with an extension is a transitional state with a defined purpose. Treating it as a permanent architecture means accumulating an ever-larger gap between your estate and the current specification, which makes the eventual move harder, not easier.
How to use it well
Three practices separate the organisations that get value from this from those that end up more confused than before.
Document which features you are bridging and why. In two years, someone will find the extension configured and have no idea whether it is load-bearing. An extension in place for a reason nobody remembers is an obstacle to the migration it was supposed to enable.
Check capability per range, not in aggregate. Extension support is expressed per card range. Building a capability profile across your actual transaction volume tells you what proportion of traffic the extension will genuinely reach, which is the number that determines whether the implementation effort is worthwhile.
Set a migration trigger, not a migration date. Dates slip. Triggers hold. Reasonable triggers include a scheme programme change that requires the newer version, an extension-covered feature being superseded by one that is not, or the proportion of your counterparties still on older versions falling below a threshold you define now while you are being rational about it.
Where it sits in a version strategy
Bridging is a tactic inside a version strategy, not a substitute for having one.
The strategy question is how your organisation handles specification change as a recurring event rather than a series of projects. New versions arrive, bulletins amend existing ones, and the device information specification increments on its own cadence tied to operating system releases. An organisation with a repeatable approach to that absorbs each change at moderate cost. An organisation without one treats each as an emergency.
The bridging extension is most valuable to the first kind of organisation, because they use it deliberately, for named features, with a defined exit. It is least valuable to the second, who tend to configure it once, forget it, and discover it years later during an upgrade that has become much harder than it needed to be.
Frequently Asked Questions
Does the bridging extension work equally for version 2.1.0 and version 2.2.0?
No, and this catches people out. The 3DS Requestor App URL was introduced in version 2.2.0 and the OOB App URL in version 2.3.1. Supporting the OOB App URL requires major SDK changes that were made for version 2.2.0 SDKs through support for universal app links, but not for version 2.1.0 SDKs. Allowing 2.1.0 SDKs to implement it without EMVCo testing available would present a significant risk of error, so EMVCo decided to support the OOB App URL only for version 2.2.0.
Does it cover card range data retrieval?
Yes. The card range data file download method, introduced in version 2.3.1, is also available for the version 2.1.0 and version 2.2.0 protocol using the bridging extension. Where the file URL is present, the file contains the entire card range data and the 3DS Server ignores any card range data and serial number present in the preparation response.
Is it a substitute for upgrading?
No. It covers selected features, and anything outside that set remains unavailable until the underlying components move. Running on an older version with an extension is a transitional state with a defined purpose. Treated as permanent architecture, it widens the gap between your estate and the current specification and makes the eventual migration harder.
How do we know whether the far end supports it?
Supported message extensions are carried in card range data alongside the protocol versions the ACS supports for that range. An extension your 3DS Server supports and the receiving ACS does not is not a working capability, so this is worth checking per range rather than assuming.
Planning a version migration? GPayments supports acquiring and issuing 3DS deployments across mixed-version estates. Speak with a 3DS specialist about your migration sequencing.