Why the 3DS Transaction Status Differs Between Messages

The 3DS transaction status element appears in more than one message, and it does not mean the same thing each time. Teams that read whichever copy arrives first, and act on it, end up with reporting that does not reconcile and occasionally with transactions taken to authorisation on the wrong basis.

This is not a defect. The difference is deliberate, and once you see why, the whole flow becomes easier to reason about.

Which message is the final one depends on the outcome

Start here, because everything else follows from it.

Where the ACS risk assessment concludes that no challenge is needed, the ACS provides its final response in the authentication response, and its processing of the authentication ends there. It never sends a results message for a frictionless transaction.

Where the assessment concludes a challenge is needed, the ACS processes the challenge and provides its final response in the results message after the challenge completes.

So the authoritative status lives in a different message depending on which path the transaction took. An implementation that always waits for a results message will hang on frictionless transactions. One that always acts on the authentication response will act early on challenged ones.

From the ACS side the completion points are equally distinct: for a frictionless transaction the ACS has finished once it sends the authentication response, and for a challenge it has finished once it sends the final challenge response.

The two statuses at the end of a challenge

Here is the part that causes the most confusion, because at the end of a challenge the status appears twice, in two different messages, serving two different consumers.

The status in the final challenge response tells the requestor to proceed to the next step with the cardholder. That means presenting the right interface: a completion message, closing the challenge iframe in a browser flow, closing the SDK in an app flow, or restarting the checkout on failure. Its values are deliberately limited to a successful or unsuccessful outcome, to keep the requestor implementation simple.

The status in the results message is what the 3DS Server uses, together with the associated authentication value, to complete the transaction, usually by proceeding to authorisation. Here the ACS has more options available, in order to give the 3DS Server more detailed information.

So the same element carries a coarse signal to the merchant’s interface and a detailed signal to the system that will act commercially on it. Both are correct. They answer different questions.

Two practical rules follow. The requestor should drive its user interface from the challenge response and nothing else. And the 3DS Server should drive its authorisation decision and its reporting from the results message, never from the coarse value the cardholder’s browser or app happened to see.

There is a related constraint worth knowing: the status should only be present in the final challenge response, and where it appears in a non-final one, the SDK should ignore it.

Why a merchant-initiated transaction cannot be challenged

A specific case that catches subscription implementations.

A merchant-initiated authentication is initiated without the cardholder present, so the ACS cannot return a status requesting a challenge, because a challenge cannot be processed by the requestor. Where a challenge is needed, the only option is to request decoupled authentication, and only where the ACS supports it. The ACS then reaches the cardholder through an alternative channel that is not part of the 3DS flow.

This is why your renewal logic needs a different branch from your checkout logic. The set of outcomes available is genuinely smaller.

Statuses that come from somewhere other than the ACS

Two cases where the status you receive was not set by the issuer’s ACS at all.

The Directory Server can create an authentication response on the ACS’s behalf, for example where it returns an attempted-authentication outcome. On versions 2.1.0 and 2.2.0 it then sets the ACS reference number equal to its own reference number and the ACS transaction identifier equal to its own transaction identifier. Version 2.3.1 and higher handle this through specific requirements.

The practical point for reporting: if your analysis groups outcomes by ACS reference number, some of what looks like ACS behaviour is Directory Server behaviour. Worth knowing before you draw conclusions about a particular issuer.

Separately, one status value is only valid in defined circumstances. On version 2.2.0, the informational status is valid where the requestor challenge indicator carried particular values in the authentication request, and Directory Servers may define additional cases of their own.

What this means for your reporting

Three things to check in your own implementation.

Are you reading the status from the correct message for each path, rather than from whichever arrives first? Frictionless and challenged transactions terminate in different places.

Are you distinguishing the coarse interface status from the detailed commercial status in your data, or storing whichever you happened to capture? These will not reconcile, and the reconciliation gap tends to be discovered during a dispute.

Are you accounting for statuses set by the Directory Server rather than the ACS when you attribute behaviour to an issuer?

A note on the value set

This article deliberately does not publish a table of status values and definitions. The set varies by version and by message, and a published table that falls out of date is worse than none, because implementers copy it.

The definitive list for your version lives in the Core Specification tables. If you are building decision logic on status values, read it there rather than from any secondary source, including this one.

Frequently Asked Questions

Which message carries the authoritative outcome?

It depends on the path. For a frictionless transaction, the authentication response is final and no results message is sent. For a challenged transaction, the results message carries the final response after the challenge completes.

Why does the status at the end of a challenge appear twice?

Because two parties need different things. The value in the final challenge response tells the requestor how to update the cardholder’s interface, and is deliberately limited to keep that implementation simple. The value in the results message gives the 3DS Server the detail it needs to complete the transaction, usually by proceeding to authorisation.

Can a merchant-initiated transaction be challenged?

Not in the normal way. Because the cardholder is not present, the ACS cannot return a status requesting a challenge, since the requestor cannot process one. The only option is decoupled authentication, where the ACS supports it.

Should we build logic on a published list of status values?

Not from a secondary source. The valid set differs by version and by message, and the definitive list is in the Core Specification tables for the version you are running. Take it from there.

Building authentication outcome handling? ActiveServer is the GPayments 3DS Server solution for acquirers, gateways and payment service providers. Speak with a 3DS specialist about outcome interpretation.