Age Verification and 3DS Attribute Checks

Age verification in 3DS is possible, and almost nobody uses it. If you sell alcohol, run a gambling platform, or operate anything a regulator expects you to keep minors out of, you already have an age verification problem and an expensive answer to it. Document upload. A third-party identity provider. A database check that fails for a meaningful slice of your customers and sends them to a support queue.

Meanwhile, at checkout, you are already sending a message to the cardholder’s bank, and the bank already knows how old they are.

EMVCo published a message extension in June 2024 that closes that gap. It is one of the least-known capabilities in the protocol and, for a specific set of merchants, one of the most commercially interesting.

What it does

The Attribute Verification Message Extension lets existing version 2.2.0 and version 2.3.1 components carry additional data about cardholder attributes such as age, name, citizenship or address for verification.

EMVCo names the intended audience directly. It is aimed at merchants offering services such as restricted goods purchases, online gambling or adult content, who are required by regulation to block access to those services by minors.

The shape is straightforward. The merchant asks a question in the authentication request. The issuer answers it in the authentication response, or after a challenge in the results message, depending on whether a challenge was needed.

What you can ask

The extension defines five attribute types you can request verification against: age, date of birth, citizenship, an identification number, and what it calls a core attribute, meaning a field already present in the main authentication message.

For the first four, you supply a value to test against and a comparison to apply. The available comparisons cover less than, greater than, less than or equal, greater than or equal, equal, not equal, and compare. The first six are the ones applicable to age and date of birth.

So an age check is expressed as a question rather than a request for data. You are not asking the issuer how old the cardholder is. You are asking whether they are over eighteen. That distinction is the whole point of the design and it is worth making explicitly to your privacy function, because it is considerably more data-minimising than the alternatives.

Date of birth is supplied in a year, month, day format. Citizenship uses an ISO country code.

The core attribute option works differently. Rather than supplying a value in the extension, you name a field already present in the authentication message and ask the issuer to compare it. The available fields cover the billing address components, the shipping address components, cardholder name, email, home and work phone numbers, and, on version 2.3.1 or higher, a tax identifier. The value itself must be populated in the main message for the field you have named.

That opens up a second use case beyond age. Verifying that the cardholder name you hold matches the name the issuer holds is a meaningful fraud signal, and it uses data you are already sending.

What comes back

The response carries more nuance than a yes or no, which is worth building for.

The result code distinguishes five outcomes: matched successfully, not matched, matched partially, the attribute is supported for verification but the request could not be completed, and the attribute is not supported for verification at all.

Those last two are the ones that shape your fallback logic. An unsupported attribute is a permanent condition for that issuer and you should stop asking. A request that could not be completed is transient and may succeed next time. Collapsing both into a generic failure means you either keep making pointless requests or you abandon a working capability.

A separate reason code explains the result: data available and verified successfully, data limited but verified successfully, data unavailable, or invalid data submitted. Invalid data submitted is a signal about your own request rather than the cardholder, and is worth alerting on.

There is also an element identifying which party set the response, distinguishing the ACS from the Directory Server, and an optional free-text field describing what method the source used for the verification, with examples such as a government source.

The timing element you need to handle

One element governs your integration flow more than any other. The response indicator tells you whether verification responses will be provided before or after challenge processing.

Where it indicates before, the verification data arrives in the authentication response and you have your answer immediately. Where it indicates after, the authentication response carries no verification data, and the answer arrives in the results message once the challenge completes.

Two consequences. Your integration cannot assume the verification result will be present in the authentication response, and code that reads it unconditionally will fail. And where the response comes from the Directory Server rather than the ACS, the indicator will always say before.

There is a further wrinkle for anyone using Secure Payment Confirmation. For merchant-initiated SPC, where the indicator in the initial authentication response says the result will come after the challenge, the 3DS Server repeats the verification request in the second authentication request.

Where this sits commercially

Be realistic about the constraint. Like every message extension, this only works where the components in the path support it, and support is signalled per card range in the card range data your 3DS Server already holds. This is not a capability you can assume across a portfolio.

That makes the first step a measurement rather than a build. Profile your card range data and establish what proportion of your actual transaction volume reaches an ACS that supports the extension. If the answer is small today, the case is for monitoring rather than integrating. If it is material, the case is strong, because the alternative verification methods you are running cost money per check and lose customers at every step.

It is also worth being clear about what this does not do. A verification result is evidence the issuer has provided about its own records. Whether that satisfies a particular regulator’s requirements for age assurance in a particular market is a question for your compliance function and the applicable rules, not one the protocol answers. Treat it as a strong input to an age assurance process rather than a replacement for one.

Frequently Asked Questions

Does the issuer send us the cardholder’s actual date of birth?

Not for an age check. You supply a value and a comparison, and the issuer returns a result against that test. Asking whether the cardholder is over a threshold returns a match result, not the underlying date. The date of birth attribute type does exist where you need to test against a specific date, but the response is still a result code rather than the cardholder’s data.

What protocol version do we need?

The extension is defined for use with existing version 2.2.0 and version 2.3.1 components, so it does not require a migration to the latest version. What it does require is that the components in the path support the extension, which is signalled per card range.

Can we verify more than one attribute in a single transaction?

Yes. The request data is structured as an array, and EMVCo’s own samples include a combined age and name verification in a single message, with a separate result returned for each attribute.

What if the issuer supports the extension but cannot answer?

The result code distinguishes between an attribute that is not supported for verification and one that is supported but where the request could not be completed. Build for both. The first should stop you asking that issuer again; the second is worth retrying.

Exploring attribute verification in your authentication flow? ActiveServer is the GPayments 3DS Server solution for acquirers, gateways, and payment service providers. Speak with a 3DS specialist about message extension support.