Stripe past_due vs unpaid vs canceled: Which Status Should Failed Payments End In?

Why This Setting Matters More Than It Looks

When a renewal payment fails in Stripe, the subscription doesn't just "fail". It moves through a sequence of statuses, and one Dashboard setting decides where it lands after the last retry: past_due, unpaid, or canceled.

Most founders never touch that setting. They find out what it does months later, when a customer comes back with a new card and it turns out their subscription can't be reactivated. Or when the subscriber count is inflated by hundreds of past_due subscriptions that will never pay again.

This guide covers:

• What each failure-related status means, according to Stripe's docs
• What happens to invoices in each status
• What access the customer should have
• How to get back to active from each one
• Which end-of-retries option to pick, and the tradeoffs

The Statuses That Matter for Failed Payments

Stripe subscriptions have eight statuses. Six of them are relevant when payments fail. Here's the summary, based on Stripe's subscription status reference:

| Status | When it happens | Invoices | Customer access | Way back to active | |---|---|---|---|---| | incomplete | First payment failed or needs authentication | Open, customer has 23 hours to pay | None yet | Pay the first invoice within 23 hours | | incomplete_expired | First payment never succeeded within 23 hours | Invoice voided, no future invoices | None | None: create a new subscription | | past_due | Payment on the latest finalized invoice failed or wasn't attempted | New invoices keep being created | Your call (grace period) | Pay the most recent invoice | | unpaid | Retries exhausted, and your settings say "mark as unpaid" | Latest invoice stays open; new invoices generated as drafts; no payment attempts | Revoke | Pay the most recent invoice | | canceled | Retries exhausted and your settings say "cancel", or you/the customer canceled | Automatic collection disabled on unpaid invoices | Revoke | None: terminal, create a new subscription | | paused | Trial ended without a payment method and the trial is set to pause | No invoices created | Revoke | Attach a payment method and resume |

Two of these (incomplete and incomplete_expired) only affect the first payment of a new subscription. For renewals, and so for most involuntary churn, the path is active → past_due → whatever you configured.

past_due: The Recovery Window

A subscription becomes past_due when a renewal payment fails. Stripe's definition: "Payment on the latest finalized invoice either failed or wasn't attempted. The subscription continues to create invoices."

While it's past_due:

• Stripe may retry the payment. Retries follow your Smart Retries or custom retry schedule, though Stripe notes the status itself "doesn't guarantee another payment attempt."
• New invoices keep being created each billing period.
• The customer still technically has a subscription. Whether they keep access is up to your app. Stripe leaves it to you.

To reactivate a past_due subscription, the customer pays the most recent invoice. Stripe moves the subscription back to active whether the payment arrives before or after the due date. Marking the latest invoice as uncollectible also returns it to active, but then you've written off the money.

Should past_due customers keep access?

Usually yes, for a short grace period. Most failures are temporary: insufficient funds, a generic decline, a card that was just replaced. If you lock people out on the first failure, you punish customers who would have paid on the next retry.

A common pattern:

• Days 0–7: full access, with an in-app banner asking them to update their card
• Days 7–14: limited or read-only access
• After retries end: revoke (which is what unpaid and canceled both signal)

Stripe's own guidance is to "notify the customer directly and ask them to update their payment details" when a subscription changes to past_due, and to revoke access when it changes to canceled or unpaid.

unpaid: Retries Are Over, the Subscription Stays

unpaid only happens if you choose it in your failed-payment settings. Stripe's docs describe it as: "The latest invoice hasn't been paid but the subscription remains in place. The latest invoice remains open and invoices continue to generate, but payments aren't attempted."

According to Stripe's collection method docs, when a subscription is unpaid, Stripe creates future invoices but leaves them as drafts. You can resend the past-due invoice and any draft invoices if you want to collect for those periods, or leave them unpaid if you stopped providing the service.

What that means in practice:

• No more automatic charges. Stripe already retried while the subscription was past_due.
• Revoke access. Stripe explicitly recommends it.
• The door stays open. If the customer pays the most recent invoice, the subscription goes back to active with the same subscription ID, price, and history.

That last point is why unpaid exists. A customer who comes back three weeks later with a new card can be restored without rebuilding their subscription.

canceled: The Terminal State

If your settings cancel the subscription after the final retry, the subscription moves to canceled. Stripe is blunt about it: "This is a terminal state that can't be updated."

On cancellation:

• Automatic collection on all unpaid invoices is disabled (auto_advance=false)
• No new invoices are created
• The subscription can't be modified, except for metadata and cancellation details

You can't reactivate a canceled subscription in Stripe. If the customer wants to come back, you collect new payment details and create a new subscription. Their original start date, any grandfathered price, and any applied coupons don't carry over automatically. You have to recreate them.

This is the main cost of canceled: every late recovery turns into a re-signup instead of a one-click payment.

What Happens When the Retries End

After the last retry fails, Stripe applies whichever outcome you picked in your failed payment settings. Stripe's docs list three options (the rest of the recovery configuration is covered in our recommended Stripe recovery settings):

| Setting | Resulting status | Invoices afterwards | |---|---|---| | Cancel the subscription | canceled | No new invoices, collection stops | | Mark the subscription as unpaid | unpaid | Continue to generate, stay in draft (or the status set in your invoice settings) | | Leave the subscription past due | past_due | Continue to be generated as open |

The tradeoffs

Cancel the subscription

• ✅ Clean data: your active subscriber count and MRR reflect people actually paying
• ✅ No invoices piling up for customers who are gone
• ❌ Late recoveries need a brand-new subscription
• ❌ Lost price grandfathering, anniversaries, and subscription history

Mark the subscription as unpaid

• ✅ Customer can be restored by paying the latest invoice
• ✅ Payments stop, so no more pointless declines on a dead card
• ❌ Needs your app to treat unpaid as "no access" (Stripe won't do it for you)
• ❌ Draft invoices accumulate, so you need a policy for them

Leave the subscription past due

• ✅ Nothing is ever closed
• ❌ open invoices keep being generated for customers who aren't paying
• ❌ Inflated subscriber and MRR numbers in any tool that counts past_due as live
• ❌ Hard to tell "just failed yesterday" apart from "failed four months ago"

Our recommendation

For most SaaS businesses: mark the subscription as unpaid, revoke access in your app on unpaid, and set a policy to void the draft invoices (or cancel the subscription yourself) after 30–60 days in unpaid.

You keep the cheap reactivation path during the window when customers actually come back, and you avoid carrying zombie subscriptions forever.

Pick cancel if you have no way to gate access on unpaid in your app, or if your pricing changes often enough that restoring an old subscription would cause more problems than it solves.

Avoid leave past due unless you have a specific reason, like manual collections on high-value B2B accounts.

A Simple Decision Flow

When a renewal payment fails, here's how the statuses and your actions line up:

1. Payment fails → subscription becomes past_due. Notify the customer with a direct card-update link and show an in-app banner. Keep access for a grace period.
2. A retry succeeds, or the customer updates their card and pays → back to active. Stop all dunning immediately.
3. Retries run out → your end-of-retries setting applies:
   • unpaid: revoke access, keep sending win-back emails, and let the customer reactivate by paying the latest invoice.
   • canceled: revoke access. Any comeback is a new subscription.
   • past_due (left as is): revoke access in your app anyway, and review these regularly.
4. After 30–60 days in unpaid with no response → cancel the subscription or void the drafts so your data stays clean.

The key point: your dunning work happens during past_due. By the time a subscription reaches unpaid or canceled, recovery is much harder, because Stripe has stopped retrying and the customer has already ignored several messages.

Webhooks to Listen For

Your app has to react to these transitions, because Stripe won't revoke access for you. The events Stripe recommends:

| Event | Use it to | |---|---| | invoice.payment_failed | Start customer notification; read the decline reason from the PaymentIntent | | customer.subscription.updated | Detect transitions to past_due and unpaid (check status) | | customer.subscription.deleted | Detect cancellation and revoke access | | invoice.paid | Restore access and stop any dunning sequence | | invoice.payment_action_required | Ask the customer to complete authentication (3D Secure) | | customer.subscription.paused / resumed | Handle trials that ended without a payment method |

A common bug: gating access on customer.subscription.deleted only. If your setting is "mark as unpaid", that event never fires when retries end, and customers keep full access indefinitely. Always check status on customer.subscription.updated too.

How Big Is Your past_due Problem?

You can count past_due subscriptions in the Stripe Dashboard by filtering subscriptions by status. Turning that into a dollar figure, and working out why those payments are failing, takes more work. You have to export, sum the monthly value per subscription, and cross-reference with the failed charges and their decline codes. Our guide on how to find failed payments in Stripe walks through the manual process, and the involuntary churn rate formula turns the result into a rate you can track month over month.

The shortcut is our free Stripe audit. You paste a restricted read-only key (or upload a CSV export), and in about 3 minutes you get your MRR at risk from past_due subscriptions, 30-day failed payment volume, the breakdown by decline code, and a playbook for your top failure reason. No account, and the key is discarded after the report.

If the number is worth chasing, Rechurn runs the recovery emails during the past_due window. You pay 15% of what those emails recover and nothing otherwise.

Key Takeaways

1. past_due is the recovery window. The subscription still exists, Stripe may still retry, and one payment on the latest invoice restores it.
2. unpaid stops the charges but keeps the subscription, so a returning customer can be reactivated by paying the latest invoice.
3. canceled is terminal. You can't reactivate a canceled Stripe subscription; a comeback means a new subscription.
4. Stripe won't revoke access for you. Your app has to gate access on unpaid and canceled via webhooks.
5. For most SaaS, "mark as unpaid" is the best end-of-retries setting, paired with a 30–60 day cleanup policy.
6. Do your dunning during past_due. That's when customers are most likely to fix their card, and when a card update link is still a one-click fix.