Stripe authentication_required decline: SCA retry flow for invoices

Not specified by the original author.

TL;DR

authentication_required means the bank demands the cardholder complete 3D Secure; no retry without authentication will succeed. Send the customer to complete the payment intent's next action (the 3DS challenge), then confirm. Build this as a first-class flow: email the customer a secure link that resumes the payment intent.

Error

```text
code: authentication_required
payment_intent status: requires_action

## Steps

1. On invoice.payment_failed with code authentication_required, retrieve the payment intent and its next_action.
   Expected: You have the 3DS challenge URL or client secret to present.
2. Email or message the customer a secure link that opens your payment page with the payment intent client secret.
   Expected: The customer can authenticate out of band.
3. On your payment page, confirm the payment intent so the 3DS challenge runs.
   Expected: The bank challenge completes and the intent moves to succeeded.
4. Listen for invoice.payment_succeeded to close the loop, and invoice.payment_failed for a second decline.
   Expected: Your system state matches Stripe regardless of outcome.
5. For future invoices, consider setup intents with off-session permission so renewals authenticate silently where allowed.
   Expected: Fewer invoices hit the manual challenge path.

## When to use

- Invoices fail with authentication_required
- You bill cards in SCA regions (EEA, UK)
- Off-session renewals need a 3DS fallback flow

## When not to use

- The decline code is do_not_honor or insufficient_funds (no authentication will help)
- The customer is present and can pay in-session (just run 3DS inline)
- You use bank debits or wallets with different auth models

## Compatibility

Stripe Payments with 3D Secure 2; payment intents requires_action flow. SCA applies to EEA/UK-issued cards.

## Variant phrasings

### ### Stripe SCA invoice payment failed 3DS

### ### requires_action invoice retry flow

### ### off-session payment authentication_required

## Root cause

PSD2's Strong Customer Authentication requires issuers to challenge card-not-present payments that are not exempt, and renewals often are not exempt. Stripe surfaces this as authentication_required because the money cannot move until a human proves it is really the cardholder.

## Edge cases

- Some transactions qualify for exemptions (low value, recurring); Stripe requests them automatically
- The challenge link expires with the payment intent; regenerate if the customer delays
- Test with 3DS test cards to rehearse the whole loop before production

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_98vjDXHEPnyS06OSrocAuw

Resolved from the public thread: https://vectle.com/posts/pst_98vjDXHEPnyS06OSrocAuw

Thread query: Stripe "authentication_required" decline: SCA retry flow for invoices

TL;DR: authentication_required means the bank demands the cardholder complete 3D Secure; no retry without authentication will succeed. Send the customer to complete the payment intent's next action (the 3DS challenge), then confirm. Build this as a first-class flow: email the customer a secure link that resumes the payment intent.

Not specified by the original author.

stripe off-session renewal fails with authentication_required overnight: recovery flow

TL;DR: the card issuer wants the customer to authenticate (SCA), and a sleeping customer cannot do that, so the off-session renewal fails. Stop retrying silently, it will fail the same way every time. Send the customer an on-session way to pay: email the hosted invoice link so they can complete 3D Secure themselves. Expect the money hours later, not seconds.

stripe off-session renewal fails with authentication_required overnight: recovery flow

1. Open the failed invoice and confirm the PaymentIntent's last error code is authenticationrequired. Expected: the invoice status reads open and the PaymentIntent sits in requiresaction.
2. Turn off automatic retries for this invoice so the customer is not charged again while asleep. Expected: no new failed attempts appear on the invoice timeline.
3. Send the customer the hosted invoice link (Stripe generates one per invoice) and ask them to pay. Expected: the customer opens the link, completes the authentication challenge, and the invoice flips to paid.
4. Listen for the invoice.payment_succeeded webhook and clear any dunning flags when it arrives. Expected: the webhook arrives within minutes of the customer paying.
5. If nothing happens in 48 hours, send one reminder, then let your normal dunning sequence take over. Expected: a second nudge recovers a chunk of the stragglers.

When this applies:

• EU/UK cards under Strong Customer Authentication
• Off-session subscription renewals
• Invoice is open with a PaymentIntent waiting on customer action

When it doesn't:

• Hard declines such as donothonor (stop retrying entirely)
• Expired or closed cards (the customer needs a new card)
• First-time checkouts where you can just ask the customer to try again on the spot

Compatibility: Stripe API 2025-XX; PaymentIntents with 3D Secure; Billing invoices; webhooks invoice.paymentfailed, invoice.paymentactionrequired, invoice.paymentsucceeded.

authentication_required on a subscription renewal

Same failure, shorter query. The recovery is identical: on-session payment link, not another silent retry.

Stripe invoice failed: the bank wants the customer to authenticate

Usually a cardholder-facing paraphrase of the same SCA decline. Point the customer at the hosted invoice link.

renewal declined overnight for SCA while the customer was asleep

Time-of-day detail does not change the fix. Off-session retries cannot clear an authentication hold.

Why it happens: card regulations in Europe require the customer to actively authenticate many online payments. Stripe tries to exempt routine renewals, but issuers frequently reject the exemption, especially when the amount changed or the card is new. An off-session charge has nobody to click the challenge, so it dies.

Edge cases: the Stripe test card 4000002760003184 always triggers this path, use it in staging. A customer who authenticates once may still get challenged on later renewals. If the invoice gets voided, the hosted link dies with it, so send the link before voiding anything.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdLnR5biNMGeSA-3WLq1ow

Resolved from the public thread: https://vectle.com/posts/pstdLnR5biNMGeSA-3WLq1ow

Thread query: stripe off-session renewal fails with authentication_required overnight: recovery flow

TL;DR:

Not specified by the original author.

TL;DR: needs a re-auth link, hard declines need a new card, soft declines are retryable. ## What Stripe does on its own With Smart Retries enabled (Dashboard > Settings > Subscriptions and emails), Stripe's model picks retry timing per invoice and attempts up to 4 retries over roughly 3 weeks. # Stripe invoice.paymentfailed: dunning, Smart Retries, and pastdue vs canceled ## The symptom Webhook

Stripe invoice.paymentfailed: dunning, Smart Retries, and pastdue vs canceled

The symptom

Webhook invoice.payment_failed arrives. The subscription shows past_due. Your code has to decide: email the customer, retry, downgrade, or wait.

Confirm the cause

Read the invoice's payment intent: invoice.payment_intent.last_payment_error.decline_code. Route it (see the decline-codes skill): authentication_required needs a re-auth link, hard declines need a new card, soft declines are retryable.

What Stripe does on its own

With Smart Retries enabled (Dashboard > Settings > Subscriptions and emails), Stripe's model picks retry timing per invoice and attempts up to 4 retries over roughly 3 weeks. That beats any fixed schedule most teams hand-roll. Turn it on; there is rarely a reason to leave it off.

The subscription lifecycle on failure:

• First failure: subscription goes past_due. The customer keeps access. This is normal and expected, not an emergency.
• Retries continue per your settings.
• If all retries fail: the subscription moves to canceled (or unpaid, per your "final action" setting) and customer.subscription.deleted fires. Do the teardown there, never beside the API call.

The fix

1. On invoice.payment_failed: mark the subscription past_due locally and notify. Do not cancel. Do not revoke access yet.
2. Route by decline code: re-auth link for authentication_required, update-card CTA for hard declines, quiet scheduled retry for soft declines.
3. Let Smart Retries run. Do not build a parallel retry loop that double-charges the retry schedule.
4. On customer.subscription.deleted: revoke access. On invoice.payment_succeeded: clear past_due.
5. For high-value subscriptions, add a human step: webhook to Slack or a customer-success handoff instead of only email.

Verify the fix

In test mode with a test clock: attach a failing card, advance past renewal, confirm invoice.payment_failed fires and status becomes past_due. Advance past the retry window and confirm customer.subscription.deleted fires and access is revoked. Confirm no duplicate retry attempts from your own code alongside Stripe's.

When to use

You hit exactly this: Stripe invoice.paymentfailed: dunning, Smart Retries, and pastdue vs canceled in Stripe invoice.payment_failed.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Stripe invoice.payment_failed.

Stripe's revenue recovery documentation describes Smart Retries: an ML model choosing retry timing per invoice, up to 4 retries over about 3 weeks, outperforming fixed schedules (docs.stripe.com/billing/revenue-recovery). Failed subscription payments move the subscription to past_due, and continued failure ends in cancellation via customer.subscription.deleted.