The Core Specification defines a fixed set of data elements. Real payment businesses have needs that a fixed set cannot cover, and rather than expand the core indefinitely, EMVCo publishes separate documents that add defined data to existing messages.
There are five 3DS message extensions published today. Most implementations use none of them, a few use one, and almost nobody has looked at the full list to see what they are missing.
How an extension works
Every extension shares the same envelope, which is worth understanding before the individual extensions make sense.
Each carries a unique identifier assigned to it, a name defined by the extension owner, a version number, and a data object holding the extension’s own content. Extensions can be included by the 3DS Server, the Directory Server or the ACS depending on the extension and the message.
The element that matters most is the criticality indicator. It is a boolean stating whether the recipient must understand the contents of the extension in order to interpret the entire message.
That single flag determines how gracefully an extension degrades. Where criticality is false, a component that does not understand the extension can process the message anyway and simply ignore it. Where it is true, a component that does not understand it cannot safely proceed.
The practical consequence for anyone planning to use extensions is that support along the path is a prerequisite, not an optimisation. Which components support which extensions is signalled per card range in card range data, alongside the protocol versions the ACS supports.
The five extensions
Bridging. The most widely relevant. Published in 2022 to enable version 2.1.0 and 2.2.0 products to use selected features introduced in version 2.3.1.0, and later updated to align with version 2.3.1.1. It is how an older estate reaches newer capability without a full migration, and it carries several things of real value, including the element reporting which exemption an ACS applied, and the card range data file download method.
It is not complete for every scenario. For instalment transactions it carries many useful elements in its recurring data object, such as recurring amount and recurring frequency, but instalment payment data itself is only present in the authentication request, so both need accounting for.
Device Acknowledgement. The smallest in scope and easy to overlook. Its documented use is to indicate the use of a Split-SDK to the ACS, which matters where a Split-SDK certified to a later version is operating in an earlier-version environment and behaving as an earlier-version default SDK. Without the signal, the ACS has no way to know what it is actually talking to.
Payment Token. Carries token-related data alongside the authentication. One concrete detail: it defines a token status indicator whose length should be read as variable up to a maximum, in line with the equivalent element in version 2.3.1.1 of the Core Specification. For anyone running tokenised traffic and trying to give the issuer full context, this is the mechanism.
Travel Industry. Carries travel-specific context. This is the clearest example of why extensions exist at all: a flight booking has attributes a generic authentication request cannot express, and a travel purchase that looks anomalous to a generic risk model may be entirely ordinary in context. The audience is narrow and the value within that audience is high.
Attribute Verification. The newest, published in June 2024. It lets version 2.2.0 and 2.3.1 components carry cardholder attribute data such as age, name, citizenship or address for verification, aimed at merchants offering restricted goods, online gambling or adult content who are required by regulation to block minors. It is substantial enough to warrant its own article, which is linked below.
Extensions move on their own cycle
A point that connects to the wider version picture.
The version management bulletin provides the list of message extensions alongside the status of the Core Specification and the device information versions, and EMVCo may release a new or updated extension independently of a specification release.
So the extension set is not fixed to a protocol version, and checking the current list is a separate task from checking which protocol version you are on. If your last review of available extensions was during your original integration, the list has changed since.
How to decide whether to use one
Four questions, in order.
Does it address a real gap? Extensions solve specific problems. If you do not have the problem, the answer is no.
What proportion of your volume can receive it? Support is signalled per card range. Profile your own card range data by volume rather than by range count, and you will get a realistic answer rather than an optimistic one.
What is the criticality setting, and how does the flow degrade? Where criticality is false, unsupported components ignore the extension and the transaction proceeds. Design for the case where the extension is present and ignored, because on a mixed estate that will be most of your traffic initially.
Who else has to change? An extension requires the components that need to process it to support it. That is a conversation with your vendor and potentially with issuers, not a configuration change.
Where most teams should start
For a typical acquiring-side implementation, the bridging extension is the one to look at first, because it is the only one whose value is largely independent of your business model. If any part of your estate is on an older protocol version, it is probably leaving capability unused that bridging would reach.
After that it depends entirely on what you sell. Travel merchants should look at the travel extension. Age-restricted merchants should look at attribute verification. Tokenised estates should look at the payment token extension. Anyone running a Split-SDK across versions will need device acknowledgement whether they planned to or not.
Frequently Asked Questions
What does the criticality indicator do?
It states whether the recipient must understand the extension’s contents in order to interpret the entire message. Where it is false, a component that does not support the extension can process the message and ignore it. Where it is true, it cannot safely proceed. It is what determines how gracefully the extension degrades on a mixed estate.
How do we know whether an extension will be honoured?
Supported message extensions are carried in card range data alongside the protocol versions the ACS supports for that range. An extension your component supports and the receiving component does not is not a working capability, so check per range rather than assuming.
Are new extensions tied to protocol releases?
No. EMVCo may release a new or updated message extension independently of the specification release cycle, and the current list is carried in the version management bulletin alongside the core specification status and device information versions.
Which extension should we look at first?
For most acquiring-side implementations, bridging, because its value does not depend on your business model and it reaches capability an older estate is otherwise leaving unused. The others are business-model specific: travel, age-restricted goods, tokenised traffic, or Split-SDK deployments.
Planning message extension support? GPayments provides 3DS Server, Access Control Server, SDK and testing components. Speak with a 3DS specialist about extension support in your deployment.