stripe authentication_required SCA retry 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

When you retry a Stripe invoice payment and get paymentintentunexpectedstate, the underlying payment intent is usually already succeeded, canceled, or requiresaction, so a blind retry cannot proceed. Retrieve the intent, read its status, and branch: succeed it forward, cancel and create a new intent, or confirm the pending action. Never retry with the same intent id without checking state first.

The query

Stripe "payment_intent_unexpected_state" error on invoice payment retry

Use this when

• A Stripe invoice payment retry returns paymentintentunexpected_state
• You retry failed invoices with the stored payment intent id
• Webhook handlers re-fire payment attempts after a failure

Not for

• A first payment attempt failed with a card decline (handle the decline itself)
• The intent is in requires_action (send the customer to complete 3DS instead)

Steps

1. Retrieve the payment intent behind the invoice before retrying; log its status. Expected output: You see succeeded, canceled, or requirespaymentmethod, not a guess.

2. If the intent already succeeded, fetch the invoice and confirm it is marked paid. Expected output: The invoice shows status paid with the charge attached.

3. If the intent was canceled or requirespaymentmethod, create a fresh payment intent or call pay on the invoice to mint a new one. Expected output: A new intent id is issued in a payable state.

4. If it is in requiresaction, surface the nextaction URL to the customer instead of retrying. Expected output: The customer completes the authentication and the intent moves on.

5. Update your retry job to re-read intent state on each attempt instead of reusing a cached id. Expected output: Retries stop colliding with terminal states.

Variant phrasings

paymentintentunexpected_state Stripe invoice retry

Stripe retry invoice payment unexpected state error

invoice payment intent already in terminal state Stripe

Root cause

paymentintentunexpected_state is a state-machine guard, not a payment failure: Stripe refuses to move an intent that has already reached a terminal state. Retrying with a stale intent id is the mismatch, and the fix is to re-derive the intent from the invoice on each attempt.

Edge cases

• Intents can expire into canceled after abandoned requiresaction sessions; check nextaction expiry too
• Idempotency keys: a retried create with the same key returns the old intent instead of a fresh one, which is often how you got here

Provenance

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

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

Thread query: Stripe "paymentintentunexpected_state" error on invoice payment retry

TL;DR: When you retry a Stripe invoice payment and get paymentintentunexpectedstate, the underlying payment intent is usually already succeeded, canceled, or requiresaction, so a blind retry cannot proceed. Retrieve the intent, read its status, and branch: succeed it forward, cancel and create a new intent, or confirm the pending action. Never retry with the same intent id without checking state first.