RecoverGuide
Recovering authentication_required declines
Last updated 28 July 2026 · written by Bruce McGinley, who builds RecoverFlow
authentication_required means the payment needs Strong Customer Authentication and only the cardholder can complete it. It is one of the nine codes where Stripe will not execute a retry, because no retry can supply what is missing.
The recovery path is invoice.payment_action_required, which fires when the invoice requires customer authentication, and a link that gets the customer to the authentication step.
On this page
Why this one is different from the other eight
The other codes that block retries describe a card that will not work: lost, stolen, revoked, blocked, mistyped. authentication_required describes a card that works fine and a customer who has not confirmed it is them.
That makes it the most recoverable of the nine by a distance. Nothing is broken, nobody has cancelled anything, and no new card is needed. The customer has to tap a button in their banking app. If you can get them to that button, the payment goes through.
It also makes it the most wasteful one to mishandle. Sending a "please update your payment method" email to someone whose payment method is perfectly good is a good way to make them think about whether they still want the subscription.
The events to handle
invoice.payment_action_required is sent when the invoice requires customer authentication. That is your trigger, and it is separate from invoice.payment_failed for good reason: the required action is different.
Handle it by getting the customer to the hosted invoice page, where Stripe will run the authentication flow. The email should say what is actually happening. Something like "your bank needs you to confirm this payment" is accurate, short, and does not imply the customer did anything wrong.
The mistake to avoid: routing this into the same dunning sequence as expired cards. The ask is different, the urgency is different, and the customer's mental state on receiving it is completely different. One is "your card broke", the other is "your bank wants a thumbs up".
Off-session is the whole game
Subscription renewals happen when the customer is not there. That is what off-session means, and it is why authentication is a problem for subscriptions in a way it is not for checkout.
Stripe's test cards make the distinction visible. 4000002500003155 requires authentication for off-session payments unless the card was previously set up, while on-session payments always require it. 4000003800000446 is already set up for off-session use, so off-session payments succeed while one-time and on-session payments still need authentication.
The practical reading: a card properly set up for off-session use at signup is far less likely to demand authentication at renewal than one that was not. If you are seeing authentication_required regularly on renewals, the fix is upstream in how payment methods are saved, not downstream in your dunning copy.
Testing it
Use 4000002760003184 to force authentication on every transaction, which is the fastest way to see the event fire and confirm your handler works. Then use 4000002500003155 for the more realistic case, where behaviour depends on whether the card was set up for off-session use.
4000000032200000 is the useful control: it requires 3D Secure on all transactions but proceeds through the frictionless flow and succeeds. If your code treats that as a failure, you are about to send dunning emails to customers who paid you. There is a fuller list in the test cards guide.
Finding yours
On a failed PaymentIntent the code sits at last_payment_error.decline_code. Count how many of your unpaid invoices carry authentication_required against how many carry a genuinely dead card.
If the authentication share is meaningful, you have a recoverable population that a card-update email will not reach, because those customers do not need to update anything. Splitting that group out is usually the single highest value change to a home built dunning sequence, and it costs nothing but a branch in your code.
Questions people actually ask
What does authentication_required mean on Stripe?
The payment needs Strong Customer Authentication, and only the cardholder can complete it. The card itself is fine. It is one of the nine decline codes where Stripe will not execute a retry, because a retry cannot provide the authentication.
Can Stripe retry an authentication_required decline?
Not usefully. It is on Stripe's list of codes that require a new payment method before retries execute. Stripe keeps the schedule running and keeps incrementing attempt_count, but the charge is not sent. The recovery path is getting the customer to authenticate, not waiting.
Which webhook fires for authentication_required?
invoice.payment_action_required, which Stripe sends when the invoice requires customer authentication. Handle it separately from invoice.payment_failed, because the customer action needed is completely different.
How do I stop authentication_required happening at renewal?
Make sure payment methods are set up for off-session use when the customer signs up. Stripe's test cards show the difference directly: a card previously set up for off-session use can renew without authentication, while one that was not may require it every time.
Should authentication_required customers get the same email as expired card customers?
No. Their card is not broken and there is nothing to update. Asking them to add a new payment method is confusing and invites them to reconsider the subscription. Tell them their bank needs them to confirm the payment, and link them to the hosted invoice page.
Where this came from
Checked against primary sources on 28 July 2026. If Stripe changes something and this page has not caught up, tell us and it gets fixed.
- Stripe: Smart Retries — the source for the 8 tries in 2 weeks default, the configurable window, and the nine code list.
- Stripe: Subscription webhooks
- Stripe: Testing — where every test card number here comes from.
If you would rather not build this yourself
RecoverFlow watches your Stripe account for failed subscription payments, stops retrying the ones that cannot succeed, and emails the customers whose card simply needs replacing. It charges 25% of what it actually recovers, with a $29 monthly floor, and nothing at all if it recovers nothing.
It is early. It is run by one person. If Stripe's own free retry settings are enough for you, use those instead, and there is a page on this site that says exactly when that is the right call.
See how the pricing works