Why Authenticated Transactions Lose Their 3D Secure Protection at Authorisation

Authentication and authorisation are separate steps, run by different systems and often by different providers. 3D Secure produces evidence that the cardholder was authenticated. The authorisation message has to carry that evidence to the issuer. If any of it is lost, altered or mismatched on the way, the issuer sees a transaction that looks unauthenticated.

The consequences show up in two places. Some issuers decline the authorisation, particularly in markets that mandate strong customer authentication. And when a fraud chargeback arrives weeks later, the protection the merchant thought it had may not apply.

What 3D Secure produces and what authorisation needs to carry

A completed EMV 3DS authentication returns a small set of values to the 3DS Server. Each one has a specific job once it reaches the authorisation message.

The authorisation should also describe the same transaction that was authenticated. Amount, currency and card (or token) need to match what the issuer authenticated, within whatever tolerance the scheme allows.

Frictionless and challenged results arrive in different messages

In a frictionless authentication, the Authentication Response (ARes) carries the final result, including the Authentication Value and ECI. In a challenged authentication, the ARes only says a challenge is required. The final result arrives later, in the Results Request (RReq) the ACS sends after the cardholder completes, fails or abandons the challenge.

Integrations that only read the ARes miss the outcome of every challenged transaction. Why the 3DS transaction status differs between messages explains this in more detail.

Where the hand-off usually breaks

Most broken hand-offs are integration problems rather than protocol problems. They are particularly common when one provider runs the 3DS Server and another runs the gateway or acquiring connection.

1. Each provider names and formats the values differently, so a value can be mapped to the wrong field, or not mapped at all, without any visible error.
2. The integration reads its result from the ARes, so challenged transactions go to authorisation without their final values.
3. The Authentication Value passes through several systems, and each may expect a different encoding or length.
4. The protocol version field is left at a default, so the network applies the wrong rules.
5. An older gateway interface has no field for the DS Transaction ID and discards it.
6. An authentication is reused for a different amount, a later split shipment or a retry after a decline. Schemes set rules on when an authentication result can be reused and for how long; subsequent payments normally need their own treatment, as described in understanding merchant-initiated authentication.
7. Attempted authentications or data-only messages are treated as if they were full authentication. Data-only transactions in particular do not move fraud liability to the issuer.

How the card schemes treat a broken hand-off

Liability and validation rules belong to each card scheme, not to the EMV 3DS specification, so the consequences must be checked scheme by scheme.

• Visa’s Visa Secure programme documentation sets a requirement for Visa Secure transactions to carry a CAVV. A transaction presented as authenticated or attempted without a valid CAVV should not be expected to receive the protection that authentication normally provides.
• When Mastercard introduced EMV 3DS support for Identity Check, it added dedicated authorisation fields for the programme protocol and the DS Transaction ID (DE 48, subelement 66). Processors document the DS Transaction ID as required in authorisation for Identity Check transactions.
• American Express, JCB, Discover and domestic schemes each define their own authentication value format and ECI usage. Do not assume Visa or Mastercard behaviour carries over.

How to check that your hand-off is working

You do not need to wait for a chargeback to find out. A practical verification routine looks like this:

1. Trace sample transactions end to end. For each scheme and for both frictionless and challenged flows, compare the values in your 3DS Server records with what your acquirer received in the authorisation. Many acquirers can report the ECI and authentication fields they saw.
2. Compare the ECI before and after. If the ECI your acquirer reports differs from the ECI returned by authentication, something along the path has changed or rejected the authentication data.
3. Review fraud chargebacks on authenticated transactions. A fraud chargeback on a transaction your records show as fully authenticated is the clearest sign of a broken hand-off. Check the dispute reason first, because liability shift covers fraud disputes, not service disputes.
4. Test after every change. Any change to the gateway, acquirer connection, 3DS Server or protocol version can alter field mapping. Include the hand-off in your regression test scope.
5. Monitor by issuer and scheme. A hand-off problem affecting one scheme or one card type is easy to miss in an aggregate approval rate.

Agree who owns the hand-off

When authentication and authorisation sit with different providers, each can reasonably assume the other is responsible for the mapping. Agree in writing who maps each field, who tests it and who is notified when either side changes its interface. Full-stack versus multi-vendor 3D Secure covers the wider architectural trade-off.

Frequently asked questions

Does an attempted authentication (ECI 06 or 01) give the merchant liability shift?

It depends on the card scheme, the market and the circumstances of the attempt. Some scheme rules give protection for certain attempted authentications; others do not. Confirm the current rules for each scheme with your acquirer rather than relying on a general answer.

How long can an authentication result be used for authorisation?

The core EMV 3DS specification does not set a single answer. Card scheme rules govern how long an authentication remains usable and whether it can cover a changed amount or a later payment. Check the rules for each scheme you accept.

What is the DS Transaction ID for?

The Directory Server assigns it to each authentication. Carried into the authorisation, it lets the card network match the authorisation to the authentication record, which is why Mastercard added a dedicated authorisation field for it.

Does a frictionless authentication carry the same evidence as a challenged one?

Yes. Both produce an Authentication Value and an ECI. The difference is which message carries them: the Authentication Response for frictionless outcomes, the Results Request after a challenge.

Reviewing your hand-off

GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs, and merchants. If you want to review how authentication results flow into your authorisations, particularly across more than one provider, speak with a GPayments 3DS specialist.