Stripe Failed Payments: When a Declined Card Cancels the Subscription and Lands in the Churn Report

Why “Cancel the subscription” turns a failed card into churn

Stripe’s subscription overview calls canceled “a terminal state that can’t be updated.” Canceling stops automatic collection of the outstanding invoices from that subscription, and a customer who wants to come back needs new payment details and a new subscription. On a monthly plan that is one lost charge; on a sales-assisted account it can be the end of a relationship nobody decided to end.

The good news is in the record itself. Every canceled subscription carries a cancellation_details field, and its reason separates three cases: cancellation_requested, “Canceled explicitly through the API or Dashboard”; payment_disputed, after a dispute was opened; and payment_failed, “Canceled automatically after payment failure, according to your billing settings.” Stripe knows which cancels were a decision and which were a declined card.

A churn chart built on status alone does not. If the report that reaches the founder counts canceled subscriptions, a customer who emailed to leave and a customer whose corporate card was reissued look the same. The first is a product or fit conversation. The second is a collections task that had a deadline — the last retry — and passed it with nobody assigned.

What runs before the last retry, and what does not

Stripe offers several recovery switches, and each one is optional. Its revenue recovery page names Smart Retries, customer emails, no-code automations and automatic card updates among them.

• Failed payment emails: with “Send emails when card payments fail” turned on, Stripe emails the customer after each failed payment, with a link to update the payment method.
• Expiring card emails: with “Send emails about expiring cards” turned on, Stripe sends an email “1 month before your customer’s card on file expires.”
• Automatic card updates: Stripe works with the card networks to update saved cards when an issuer replaces one. Its cards page says this is widely supported in the United States, that support abroad varies, and that “It isn’t possible to identify cards that support automatic updates.”
• Automations: Stripe publishes a recipe for annual subscribers — Smart Retries up to 8 times within 2 months, then an optional 7-day delay “as an additional grace period for manual outreach,” then cancel.

Every item on that list either retries a card or sends an email. None of them calls anyone. On a B2B account the email goes to whatever billing address sits on the customer record, which may belong to someone who changed roles since the contract was signed. Stripe’s own annual-subscriber recipe leaves a gap for manual outreach; whether a person fills it is a question for the company, not for Stripe.

How to count Stripe failed-payment cancellations in the company’s own account

The count takes an afternoon with read-only access, and it answers a narrower question than any benchmark: how much of last quarter’s churn was a declined card, and did anyone speak to those accounts first?

• List every subscription canceled last quarter, with its plan, billing interval and monthly amount.
• Split them by cancellation reason: payment_failed, cancellation_requested, payment_disputed. The field sits on each subscription record; a developer can pull it through the API with a restricted key that can only read.
• For each payment_failed cancel, note the final invoice, its attempt count and the decline: a hard decline needed a new card, a soft one might have cleared on a later try.
• Note whether the failed-payment and expiring-card emails were switched on at the time. Stripe keeps email logs on the Customers page for the last 60 days, so check recent cases first.
• From the CRM, take the date of the last human touch — call, email from a person, meeting — before the cancel date.
• Add the subscriptions sitting in unpaid or past due today: they have not churned yet, and they are the ones a person can still reach.

Illustrative example: a company finds 40 canceled subscriptions last quarter. Thirty were cancellation_requested; ten were payment_failed, worth $6,000 in monthly recurring revenue together. Four of the ten were annual accounts, and for none of them does the CRM show a human touch between the first failed charge and the cancel. The figure that matters is not ten cancels; it is $6,000 a month that left without a decision, and four phone calls that were never on anyone’s list.

Which setting fits a sales-assisted B2B account

There is no universal right answer, and Stripe does not offer one. Each outcome trades one risk for another. Cancel keeps the books clean and the product locked, at the price of ending accounts automatically. Unpaid keeps the subscription in place without charging it; Stripe’s overview says to revoke product access when a subscription is unpaid, and invoices keep generating as drafts that someone must later collect or mark uncollectible. Past due keeps billing and retrying, which suits a customer who will fix the card and can leave a departed customer accumulating open invoices. Pause stops new invoices for eligible subscriptions until the customer resumes.

Invoiced customers follow a different track. For subscriptions with collection method send_invoice, Stripe’s documentation describes reminders and an optional action 30, 60 or 90 days after an invoice becomes past due: cancel, mark unpaid or leave past due. An annual contract paid by invoice can be canceled by that setting just as a card plan can by the retry setting.

What a founder-led company can decide is who owns the window between the first failure and the last retry. One workable rule: any failed payment above a set monthly amount, or on an annual plan, goes to a named person the same day, with the account’s contract owner copied. Stripe’s automations can email the team when a high-value invoice is overdue; the call itself is still a person’s job.

How do you reduce SaaS churn from failed payments?

Reduce it by working failed payments before the last retry: let Stripe’s recovery tools collect what they can, and have a named person reach the accounts they cannot. Stripe describes Smart Retries as a way to retry failed payments “to prevent involuntary churn due to temporary issues,” and its Dashboard already shows which of the remaining accounts are worth a call.

Stripe’s revenue recovery overview in the Dashboard shows where the leak sits: failed payments and the failure rate on first attempts, the recovery rate, recovered volume split into retries, emails and other methods, and the top five decline codes. It also lists the top customers in recovery, whose payments failed and are still being retried, with the amount and how long each has been a customer. Stripe’s advice on that table: “Consider reaching out to these customers manually depending on their value to potentially save revenue.”

Switching the failed-payment setting from cancel to unpaid does not shrink the churn figure. Stripe’s Billing analytics counts a subscription that is canceled or marked unpaid as churn and takes it out of MRR, which includes only active and past due subscriptions. Unpaid keeps the account open to collection: Stripe’s API reference says that after a customer sends updated payment information, the company may choose to reopen and pay the closed invoices. Leaving subscriptions past due keeps them in MRR and in the active subscriber count while the invoice is still uncollected. A sequence that fits a founder-led company:

• Set a baseline: this quarter’s failure rate and recovery rate from the revenue recovery overview, plus the payment_failed count and the unpaid subscriptions from the count described above.
• Check the switches: where the recovery rate is lower than expected, Stripe’s own suggestion is to turn on its retries and failed payment emails, so confirm both are on before adding anything else.
• Give the table an owner: one named person opens the top customers in recovery table each week and calls the accounts above the company’s set threshold while Stripe is still retrying them.
• Compare next quarter: the same four figures side by side, before deciding whether the setting or the staffing needs to change.

When an outside review is not worth it — and where ours fits

If last quarter’s payment_failed cancels are zero or a rounding error, there is nothing here to buy. If the founder can run the count above in an afternoon, the founder should: the six steps need no consultant, and the answer belongs to the company either way. A dedicated failed-payment tool is a separate decision; it works continuously on what it is connected to, and it is a fine choice when the volume of small card failures is the whole problem.

Our Revenue Review is for a wider question. It reads one company’s own records once — Stripe or Chargebee, HubSpot, Salesforce or Pipedrive, and product analytics — through read-only access, and follows accounts across all six hand-offs, from the trial that ended with no human conversation to the card that failed and the renewal nobody worked. For a B2B SaaS RevOps consultant that is the job: a monthly dollar figure on each leak, a ranked list of fixes and a 90-day plan. It installs nothing and changes no Stripe setting. It takes two weeks, and the report is the company’s to keep. There are no client case studies on this site yet, and we would rather say so than invent one.

If the numbers suggest it, the next step is a free 20-minute call. Bring the payment_failed count; it is the fastest way to tell whether the rest of the Review is worth the fee.