Stripe Subscription Canceled Automatically: How to Fix It (And Prevent It Forever)

Stripe canceled the subscription because all payment retries were exhausted and your Billing settings are configured to "Cancel subscription" after final retry failure. To fix it: change the setting to "Mark as unpaid" or "Leave as past due," then recreate canceled subscriptions via the API. To prevent it permanently, add a dunning email sequence so customers update their cards before retries run out.

Why Stripe Cancels Subscriptions Automatically

When a subscription payment fails, Stripe enters a retry cycle. either Smart Retries (ML-optimized timing) or a fixed schedule you configure. After all retries are exhausted (typically 4 attempts over ~3 weeks), Stripe takes a final action based on your settings in Dashboard > Settings > Subscriptions and emails > Manage failed payments.

If that setting is set to "Cancel subscription," Stripe permanently cancels the subscription object. The subscription status changes to canceled, the customer loses access, and. critically. You cannot reactivate a canceled subscription. You must create a brand new one. This is the #1 reason founders see subscriptions silently vanishing from their dashboard.

// Retrieve the subscription to see why it was canceled
const subscription = await stripe.subscriptions.retrieve('sub_xxx');

console.log(subscription.status);
// "canceled"

console.log(subscription.cancellation_details?.reason);
// "payment_failed". Stripe auto-canceled after retry exhaustion

console.log(subscription.canceled_at);
// Unix timestamp of when Stripe canceled it

// Check the latest invoice to see the decline code
const invoice = await stripe.invoices.retrieve(
  subscription.latest_invoice
);
console.log(invoice.last_payment_error?.decline_code);
// e.g. "insufficient_funds"

The three possible settings after retry exhaustion are: (1) Cancel subscription. permanently ends it, customer loses access, subscription object cannot be reused. (2) Mark as unpaid. keeps the subscription alive but blocks access until the invoice is paid. (3) Leave as past due. keeps the subscription active with access, giving you maximum time to recover the payment. Most SaaS founders should use option 2 or 3.

Quick Fix (Manual)

If subscriptions have already been canceled, here's how to recover them right now:

// Step 1: Get the canceled subscription details
const canceled = await stripe.subscriptions.retrieve('sub_canceled_xxx');

// Step 2: Create a Billing Portal session so the customer
// can update their payment method first
const portal = await stripe.billingPortal.sessions.create({
  customer: canceled.customer,
  return_url: 'https://yourapp.com/account',
});
// Send portal.url to the customer via email

// Step 3: Once the card is updated, recreate the subscription
const newSub = await stripe.subscriptions.create({
  customer: canceled.customer,
  items: canceled.items.data.map(item => ({
    price: item.price.id,
    quantity: item.quantity,
  })),
  // Copy metadata from original subscription
  metadata: {
    ...canceled.metadata,
    original_subscription: canceled.id,
    reactivated_at: new Date().toISOString(),
  },
  // Use default_payment_method if set, otherwise Stripe
  // uses the customer's default payment method
  payment_behavior: 'default_incomplete',
  payment_settings: {
    save_default_payment_method: 'on_subscription',
  },
});

console.log(newSub.id);     // "sub_new_xxx"
console.log(newSub.status); // "incomplete" until payment succeeds

Permanent Fix (Automated)

The real fix is ensuring payment retries never exhaust in the first place. That means recovering the payment before Stripe gives up. Here's the full prevention stack:

Step 1: Change your retry exhaustion behavior. Go to Dashboard > Settings > Subscriptions and emails > Manage failed payments. Set the action to "Mark as unpaid" instead of "Cancel subscription." This keeps the subscription object alive, giving you unlimited time to recover the payment without losing the customer relationship.

Step 2: Enable Smart Retries. In the same settings panel, turn on Smart Retries. Stripe's ML model picks the optimal retry time based on the decline code and card issuer patterns. This recovers 5-10% more than a fixed retry schedule.

Step 3: Add a dunning email sequence. This is the biggest lever. During the 3-week retry window, you should be emailing the customer to update their card. A 5-7 email sequence with escalating urgency recovers 40-55% of failed payments. compared to 10-15% with Stripe's single built-in email. This is the key to preventing involuntary churn.

SaveMRR automates all three steps. Paste your Stripe restricted API key and SaveMRR immediately: changes your retry exhaustion setting to prevent auto-cancellation, runs a 7-email dunning sequence with one-click card update links, sends pre-dunning card expiry alerts before failures happen, and tracks every recovery in real-time. The first $200 recovered free.

// Without SaveMRR, you'd need to monitor for cancellations:
app.post('/webhooks/stripe', async (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body, req.headers['stripe-signature'], endpointSecret
  );

  if (event.type === 'customer.subscription.deleted') {
    const subscription = event.data.object;

    // Was this an auto-cancellation from failed payments?
    if (subscription.cancellation_details?.reason === 'payment_failed') {
      // Alert your team
      await notifyTeam({
        customer: subscription.customer,
        mrr_lost: subscription.items.data[0].price.unit_amount / 100,
        decline_code: 'check latest invoice',
      });

      // Try to win them back
      const portal = await stripe.billingPortal.sessions.create({
        customer: subscription.customer,
        return_url: 'https://yourapp.com/reactivate',
      });

      await sendReactivationEmail(subscription.customer, portal.url);
    }
  }

  res.json({ received: true });
});

// SaveMRR prevents auto-cancellation from ever happening.
// No webhook code. No manual reactivation. No lost customers.

Related Stripe Billing Issues