Challenge lifecycle

A session moves through a fixed set of states. Two of them are terminal and cannot be reopened.

created	Session exists, challenge not yet rendered. Expires in 10 min if untouched.
method	Silent `threeDSMethodData` step in progress. Up to 10 s.
challenged	Waiting for the buyer. Timer per issuer, 5 to 15 min, shown to the buyer.
authenticated	Terminal. `transStatus` is `Y`.
failed	Terminal. `transStatus` is `N` or attempts exhausted.
unavailable	Terminal. `transStatus` is `U`.
expired	Terminal. Timer ran out or the buyer closed the window.

Attempts

Three attempts by default, configurable per merchant between one and five. A failed attempt does not end the session; the third does. Remaining attempts are never disclosed on screen — the issuer decides that, and the challenge has to match.

Timeouts

The buyer-facing timer comes from the issuer challenge window. When it hits zero the session expires and a authentication.expired notification fires. Your order should not sit waiting: give the buyer a route back into checkout with a fresh session.

Resend

POST /v2/authentications/{id}/resend re-issues in the same mode, three times maximum, 30 s apart. It does not reset the timer — a resent code inside a dying window still dies with it.

Abandonment

Closing the window stops the clock but does not finish the session. If the buyer returns through the link, the challenge resumes. After expiry the session is dead and a new one has to be created; reusing a finished authenticationId returns 409 session_finished.

What the merchant must not do

Do not treat returnUrl as success. The buyer can reach it with the back button.
Do not create a new session on retry loops. Each one is a new acsTransID and inflates the audit trail.
Do not authorise before the notification. A card marked as 3DS but not yet authenticated will be downgraded to liability shift absent.
Do not surface U as a decline. The issuer did not decide; your risk policy has to.

Authentication outcome is not authorisation. A Y means the cardholder was verified and liability moves to the issuer. Whether the card has funds, is blocked or matches the billing address is a separate decision taken downstream.

Related: method step · error codes