authentication_required: what this Stripe decline code means and why only the customer can clear it

What it means

This is a precondition, and a refusal only in form. The issuer is willing to approve the payment once the cardholder authenticates it, typically through 3D Secure, and the decline is how that requirement travels back to you. Regulation drives much of it: Strong Customer Authentication in the European Economic Area and the UK requires authentication for many online payments, and issuers under such regimes enforce the requirement by declining what arrives without it.

The awkwardness for subscriptions is structural. Authentication needs the cardholder present, and a renewal is by definition a payment made without them. The networks and the regulation both leave room for merchant-initiated payments on cards that were authenticated at setup, which is why a properly established subscription sees this code rarely. When it appears anyway, the usual stories are a card saved without an on-session setup, an issuer that wants a fresh challenge regardless, or a change the issuer treats as a new arrangement.

No retry can answer a challenge. The failing step belongs to the customer, and Stripe's next step for off-session payments says as much: notify the customer to return and complete the payment. There is also a documented edge worth knowing: if the code comes back even after a successful authentication, Stripe's guidance is that the customer contact their issuer, because at that point the inconsistency sits on the issuer's side.

In Lirova this code is also the cleanest demonstration that the decline code is not the whole routing. A payment waiting on authentication announces itself in the PaymentIntent's own state before any decline code is read, and state outranks the code's lane, as an issuer advice code does. The case ends up in front of the customer by whichever signal arrives first.

Why it happens

1. Regulation doing its job

   Strong Customer Authentication and its relatives require authentication for many online payments. An issuer under such a regime declines unauthenticated attempts as a matter of course, and the code is the mechanism rather than a judgement.

2. A card saved without on-session setup

   The allowances that keep renewals quiet generally assume the card was authenticated when it was set up for future use. A card that skipped that step invites a challenge on the charge instead.

3. An issuer that wants a fresh challenge

   Even properly established cards get challenged: risk signals, a changed amount or issuer policy can all trigger one. The setup lowers the odds without deleting them.

4. A challenge that was never completed

   On-session flows drop challenges too: a closed tab, an unhandled redirect. A related code, authentication_not_handled, marks the case where the integration proceeded without running the required authentication at all, and the fix there is the 3D Secure flow itself.

Common mistakes

• Retrying without the customer

  Every automated attempt re-asks a question only the cardholder can answer, and fails identically. A run of unauthenticated machine attempts also reads poorly under a regime built to require a human, so the retries cost something and buy nothing.

• Sending the update-your-card email

  The card is usually fine. What the payment needs is the customer completing it in a flow that can run the authentication, which is why the useful link lands them somewhere that performs 3D Secure rather than in a form that collects new card details.

• Missing that it is an integration signal

  If this code, or authentication_not_handled beside it, appears often for on-session payments, the checkout is not running challenges it should. That is a fix in code rather than in dunning, and no amount of customer email substitutes for it.

How Lirova handles it

authentication_required carries the request_update lane: zero retries, and a message that puts the payment back in front of the customer. It is also the clearest case of the lane not being the decision. A payment waiting on authentication is visible in the PaymentIntent's state before any decline code is read, and state outranks the code's lane in the classifier, as an issuer advice code does. So this case reaches the customer by whichever signal arrives first, and the code's own lane is the fallback rather than the driver. The destination is the same either way, because the constraint is the same either way: only the cardholder can complete an authentication, and the only useful automation is the kind that brings the payment back to them.

FAQ

Related codes

• do_not_honor
• transaction_not_allowed
• card_declined