Guides · Updated October 27, 2026

Stripe subscription canceled or past due, but the user still has access

A customer canceled, or their card stopped working, and they can still log in and use the paid plan. Usually nothing is broken on Stripe's side: Stripe changed the subscription's status and sent an event, and your app either didn't receive it, didn't handle that case, or reads the wrong field. This guide explains the statuses and events involved, the common bugs, and how to find the customers it already affects.

What each status means for access

Stripe's subscription statuses are listed in Stripe: How subscriptions work. In short:

• trialing and active: Stripe says you can provision access.
• past_due: payment on the latest finalized invoice failed or wasn't attempted. The subscription keeps creating invoices, and Stripe might retry the payment, but this status doesn't guarantee another attempt.
• unpaid: only happens if your Dashboard settings choose it after retries end. Invoices keep being created but no payment is attempted. Stripe's docs say to revoke access here, because payment was already attempted and retried while the subscription was past_due.
• canceled: the subscription ended. It's a terminal state; to bill the customer again you create a new subscription.
• incomplete and incomplete_expired: the first payment hasn't succeeded (Stripe allows 23 hours) or never did.
• paused: a trial ended without a default payment method and the subscription was set to pause. No invoices are created until it's resumed.

Stripe's guidance on tracking subscriptions sums it up: when a subscription changes to past_due, notify the customer and ask them to update their payment details; when it changes to canceled or unpaid, revoke access (Stripe: Using webhooks with subscriptions).

The events that should change access

• customer.subscription.updated: sent when a subscription starts or changes, including status changes like active to past_due, and when cancel_at_period_end is set to true.
• customer.subscription.deleted: sent when a subscription ends, whether it was canceled immediately or reached the end of a period it was scheduled to cancel at (Stripe: Cancel subscriptions).
• invoice.payment_failed: a payment for an invoice failed. Its attempt_count tells you how many attempts have been made (Stripe: Automatic retries).
• invoice.paid: the invoice was paid. Stripe's docs say to retrieve the subscription and confirm it's active before extending access, since a paid invoice doesn't always make the subscription active.
• customer.subscription.paused and customer.subscription.resumed: sent when the status changes to and from paused.

Why the user still has access

• The app only listens for checkout.session.completed. Access is granted on purchase and never touched again. Every later cancellation and failed renewal is ignored.
• It handles customer.subscription.deleted but not updated. Cancellations are caught, but a move to past_due or unpaid arrives as customer.subscription.updated, so customers whose card fails keep access until (and unless) the subscription is eventually canceled.
• Your failed-payment setting is "leave past due". After the final retry, Stripe can cancel the subscription, mark it unpaid, or leave it past_due (Stripe: Subscription status after retries). If it's left past_due and your app treats past_due as paid, that customer keeps access with no end date. No deleted event ever comes.
• The app checks a boolean set once. An is_pro or plan column set at checkout, with no code path that sets it back, will never reflect a status change.
• Events failed and were never resent. If your webhook endpoint was down or returning errors, the events that should have revoked access may have exhausted their retries. Check the endpoint's Event deliveries in the Dashboard. Our webhook secret guide covers finding and resending failed events.
• Events arrived out of order. Stripe doesn't guarantee event order. If your handler writes the status from each event's payload, an older updated event processed after a newer one can put a canceled customer back to active. Fetch the subscription's current status from the API when an event arrives instead.
• The user is matched to the wrong subscription. A customer with an old canceled subscription and a new active one, or two Stripe customers with the same email, can confuse a lookup that takes the first result. See How to find Stripe customers who paid but don't have access for matching traps.

Two cases that are not bugs

• Canceled at period end. When a subscription is set to cancel at the end of the period, it stays active and the customer keeps access until then. They can also undo it before the period ends (Stripe: Cancel at end of period). The customer portal works this way too: after canceling there, customers can renew until the billing period ends (Stripe: Configure the customer portal). Show "your plan ends on …" rather than revoking early. Watch out for canceled_at: Stripe's API reference says that for these subscriptions it holds the time of the cancellation request, not the end of the period (API: Subscription object), so it's set while the subscription is still active.
• Payment collection is paused. Pausing payment collection is meant as a grace period: the subscription stays active, invoices keep being generated, and Stripe's docs say the customer keeps access (Stripe: Pause payment collection).

Decide your past_due policy

Stripe leaves this one to you. Some founders keep access during retries so a customer with an expired card isn't locked out while they update it; others cut access on the first failure. Either is fine if it's deliberate. Look at your retry settings: Stripe's docs say Smart Retries can run for 1 week to 2 months, with a recommended default of 8 tries within 2 weeks, and then your setting decides whether the subscription becomes canceled, unpaid or stays past_due (Stripe: Smart Retries). If you keep access during past_due, make sure the setting after the last retry is cancel or mark unpaid, so the grace period actually ends.

A handler that follows the status

The safest pattern is to treat every relevant event as a prompt to re-read the subscription and set access from its current status, rather than trusting each event's contents. A sketch, in the style of Stripe's Node library:

// Decide access from the subscription's current status, fetched from Stripe.
// Adjust GRACE to your own policy for past_due.
const ACCESS = new Set(["active", "trialing"]);
const GRACE = new Set(["past_due"]); // remove this line to cut access as soon as a renewal fails

async function syncAccess(subscriptionId) {
  const sub = await stripe.subscriptions.retrieve(subscriptionId);
  const hasAccess = ACCESS.has(sub.status) || GRACE.has(sub.status);
  await db.users.update({ stripeSubscriptionId: sub.id }, {
    hasAccess,
    stripeStatus: sub.status,
    cancelAtPeriodEnd: sub.cancel_at_period_end, // show "ends on …", don't revoke yet
  });
}

// Call syncAccess(sub.id) for customer.subscription.updated,
// customer.subscription.deleted, customer.subscription.paused / resumed,
// and for invoice.paid / invoice.payment_failed (use the invoice's subscription).

Verify the webhook signature before processing, record processed event IDs so retries and resends are harmless, and return 200 quickly.

Find the customers it already affects

1. Export subscriptions from Stripe. In the Dashboard's subscriptions list, filter by status: Canceled, Past due and Unpaid. Export each list with the customer email and status. With the API, status=all on List subscriptions includes canceled ones.
2. Export who has access in your app. Every user (or team) currently on a paid plan, with email and, if you store it, the Stripe customer or subscription ID.
3. Compare. Anyone on a paid plan in your app whose only subscriptions are canceled or unpaid is getting the product for free. Anyone whose subscription is past_due needs a decision under your policy above. Before acting, check they don't also have a separate active subscription, a one-time purchase or a comp.
4. Fix the data, then the code. Downgrade the affected users (consider emailing past_due customers first, since some just need to update a card), then fix the handler so it doesn't happen again.

PaidCheck's free report runs step 3 for you: with a read-only restricted key and your user list (CSV, Supabase function or HTTPS endpoint), it lists users who still have access while their subscription is canceled, unpaid or past_due, along with failed webhook events from the last 30 days. Paid plans run that check daily and send an alert email when a check finds a new issue.

FAQ