Guide

Stripe is not retrying your failed invoice. Here are the nine reasons why.

Last updated 16 August 2026 · written by Bruce McGinley, who builds RecoverFlow

Start with one field

Pull the invoice and look at next_payment_attempt. Stripe documents it as the time at which payment will next be attempted, and as null for invoices where collection_method=send_invoice.

If it holds a timestamp, Stripe does intend to retry and your problem is timing, not configuration. Wait for that moment and check again. If it is null, one of the nine below is true.

While you are there, note status and attempt_count. An invoice that is draft is not being collected at all. An attempt_count that keeps rising while nothing appears in your payments list is the signature of cause 2.

The four Stripe states outright

Stripe's Smart Retries page lists these as the conditions under which it does not retry payments. They are quoted, not inferred.

1. No payment methods are available. There is nothing to charge. Stripe retries against the first available payment method in a documented order: the subscription's default_payment_method, then the subscription's default_source, then the customer's invoice_settings.default_payment_method, then the legacy customer.default_source. Check all four, in that order.

   There is a trap here worth knowing. Stripe says that when you update payment methods after a failed attempt, you should update the field where the previous payment failed. If the subscription has a default_payment_method and you only update customer.invoice_settings.default_payment_method, Stripe carries on retrying the subscription's one. Your customer added a working card and nothing changed.

2. The issuer returned a hard decline code. Nine codes stop execution: incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level and transaction_not_allowed. Read last_payment_error.decline_code on the failed PaymentIntent.

   Stripe is precise about what happens next, and it is not what most people expect: retries continue to be scheduled and attempt_count continues to increment, but retries only execute after a new payment method is detected, and unexecuted retries do not create a new Charge. So the invoice looks busy while nothing is being attempted. Full breakdown of the nine.

3. The payment card is India-issued. Check card.country on the payment method for IN. Recurring payments on India-issued cards run under the Reserve Bank of India's e-mandate rules, which require a registered mandate authenticated by the cardholder, a pre-debit notification at least 24 hours before each charge, and fresh authentication above 15,000 INR. Stripe cannot satisfy that with a silent background retry. Watch for payment_intent_mandate_invalid and india_recurring_payment_mandate_canceled on the PaymentIntent.

4. The Stripe Connect account has been disconnected. If you are a platform, the merchant may have revoked you. Stripe sends account.application.deauthorized when a user disconnects your platform from their account. If you are the merchant and an app was retrying on your behalf, the same event is why it stopped.

The five that are your own configuration

None of these are failures. They are settings doing exactly what they say, usually set months ago by someone else.

5. collection_method is send_invoice. Stripe documents the two values plainly: with charge_automatically it attempts payment using the default source attached to the customer, and with send_invoice it emails the invoice to the customer with payment instructions. There is no card charge to retry, which is why next_payment_attempt is documented as null for these. What you want instead is the unpaid invoice reminder, which is a separate setting and is covered in the free settings checklist.

6. auto_advance is false. Documented as controlling whether Stripe performs automatic collection of the invoice, and if false, the invoice's state does not automatically advance without an explicit action. An invoice created by your own code with auto_advance off will sit there indefinitely, correctly, forever.

7. The retry schedule is finished. Stripe's wording is that after the final payment attempt, no further payment attempts are made, and that changing your subscription settings only affects future retries. Widening the window today does not give an already-exhausted invoice more chances. Check the configured schedule at Billing > Revenue recovery > Retries and compare it with attempt_count.

8. The subscription already moved on. When recovery fails, the subscription transitions according to your setting: cancel it, mark it unpaid, or leave it past_due. The unpaid branch is the one that confuses people, because Stripe documents that invoices continue to be generated and stay in a draft state. New invoices keep appearing and none of them are collected, which looks exactly like a broken retry engine. Read subscription.status and invoice.status together.

9. It is a local payment method and retries are off. Stripe is explicit that by default it does not automatically retry failed payments made with local payment methods. ACH Direct Debit, ACSS, Bacs, SEPA and both Australian and New Zealand BECS all need the Local payment methods section turned on. Even switched on, the allowances are small and the only retryable failure is insufficient funds.

The whole checklist in one table

One more thing that looks identical and is not on the list

If you have ruled out all nine and attempts are still coming back failed without ever reaching the bank, check whether the attempt was blocked rather than declined.

Visa's rules broadly prohibit more than 15 retries of a single payment over 30 calendar days, and Stripe blocks subsequent retry attempts after the 15th on a Visa transaction where it judges a low chance of authorization. That charge reports an outcome.type of blocked with an outcome.reason of previously_declined_do_not_retry, while the error your code sees is a plain generic_decline. It is a different failure from every cause above, because here Stripe did schedule the retry and did try to send it.

This is easy to miss because it hides inside your most boring decline code. There is a full page on the reattempt budget, including why it is a separate limit from the nine codes.

Questions people actually ask