customer.subscription.deleted

When it fires

• Customer cancelled immediately.
• Customer cancelled at period end, and the period has now expired.
• Stripe ended the subscription after all failed-payment retries.
• You ended the subscription manually via the API.

Cancel now vs cancel at period end

cancel_at_period_end = false ends access right away and fires the event immediately. cancel_at_period_end = true keeps the subscription active until the current billing period ends; the event fires only at that point. Most SaaS uses period-end cancellation so customers get what they paid for.

Watch for the cancellation_details.reason field. The common values are cancellation_requested (voluntary), payment_disputed, and payment_failed (involuntary). Treat involuntary cancellations as failed-payment recovery, not lost causes.

Example event payload

{
  "id": "evt_1Q...",
  "type": "customer.subscription.deleted",
  "data": {
    "object": {
      "id": "sub_PaA...",
      "customer": "cus_PaA...",
      "status": "canceled",
      "canceled_at": 1758500000,
      "cancel_at_period_end": false,
      "cancellation_details": {
        "reason": "cancellation_requested",
        "feedback": "too_expensive",
        "comment": null
      },
      "items": { "data": [ { "price": { "id": "price_..." } } ] }
    }
  }
}

What email to send

Hi {{first_name}},

You just cancelled {{product}}. No pressure — but if you have 30 seconds, I'd love to know what we got wrong or what was missing.

Anything you share goes straight to me. No surveys, no sales follow-up.

Thanks for trying it,
{{founder}}

Send this within an hour of the event. Plain text. From a real person. Not from a marketing address.

How to capture the reason

1. Listen for the customer's reply on an inbound email webhook.
2. Classify the reason. Pricing, missing feature, too complex, switched tool, not using it, business changed.
3. Store the reason against the customer record for later win-back.
4. When you ship something that addresses the reason, email the matching cohort.

How to queue win-back

Win-backs only convert when something has genuinely changed. Tie captured reasons to product changes:

• Missing feature → email when the feature ships.
• Pricing → email when you launch a smaller plan.
• Too complex → email when you simplify onboarding.
• Switched tool → email when you close the specific gap.
• Failed payment → email the moment the card update path opens.

When to use this page

Use this as the reference for wiring your cancellation workflow, or when debugging why a subscription appears canceled in Stripe without anyone on your team having seen it. For the wider event map, see the Stripe Webhook Event Decoder.

What to do next

Building this whole pipeline — cancellation webhook, founder email, inbound reply capture, reason classification, win-back queue — is a real engineering project. ChurnNote already does it for you.

Frequently Asked Questions