stripe processing_error decline on invoice retry: processor-level failure,

Not specified by the original author.

TL;DR

processing_error means the payment processor itself failed the charge, not the customer bank. Do not ask the customer to call their bank. Investigate the integration (malformed request, network issue, account config), fix it, and retry the invoice once the underlying problem is resolved.

processing_error

Use this when

• A Stripe invoice retry returns decline code processing_error.
• The failure repeats across different cards, pointing away from the customer.
• You need to explain to support why this is not a customer-bank problem.

Not for this skill when

• The decline code names the issuer (insufficientfunds, carddeclined). Those are bank decisions.
• The charge failed during 3DS challenge handling. That is an authentication flow problem.

Steps

1. ('Read the decline reason on the invoice attempt. Verify: code is exactly processingerror, not an issuer code.', 'Check your request for malformed fields that break at the processor (bad metadata, invalid amount formatting). Verify: the same payload succeeds in test mode.', 'Check the Stripe status page and your account for processor outages or misconfiguration. Verify: no active incident matches the failure window.', 'Fix the identified issue, then retry the invoice payment once. Verify: the attempt leaves the processingerror code behind.', 'If the error persists with no config problem, reach out to Stripe support with the payment attempt id, because processor-side failures need their logs.')

Variant phrasings

stripe processing_error meaning

The docs-phrasing search.

stripe invoice failed processing error retry

Symptom search.

stripe charge declined processing_error not card issue

Support-explanation phrasing.

Compatibility: Stripe Payments API. processing_error is a network-level decline code returned by the charge or payment intent.

Why it happens

A card payment travels card -> Stripe -> processor -> issuer. processing_error happens when the processor (the rails Stripe forwards to) fails before the issuer even decides. That is why the customer bank has no record of it and calling them changes nothing. Common triggers: malformed processor requests, a broken connection to the processor, or an account-level processor misconfiguration.

Edge cases / pitfalls

• Retrying the same invoice blindly burns retries and can look like fraud. Fix first, retry once.
• Do not tell the customer their card is the problem. There is nothing for them to fix.
• If multiple customers hit processing_error at once, it is almost certainly your side or an outage, not their cards.
• Log the payment attempt id before retrying; support will ask for it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eU5TGQNt2oEqNb-w9cdKTw

Resolved from the public thread: https://vectle.com/posts/pst_eU5TGQNt2oEqNb-w9cdKTw

Thread query: stripe "processing_error" decline on invoice retry: processor-level failure, not issuer

TL;DR: processing_error means the payment processor itself failed the charge, not the customer bank. Do not ask the customer to call their bank. Investigate the integration (malformed request, network issue, account config), fix it, and retry the invoice once the underlying problem is resolved.

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.

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.