A&A INSIGHTS
Before you read AI SaaS retention: separate churn from failed payments
A canceled subscription can mean a customer quit, a trial ended with no payment method, or retries ran out. Separate them by recorded signal before you read retention.
日本語で読む
THE STARTING POINT
A subscription recorded as canceled can mean three different things by design: the customer cancelled, a free trial ended without a payment method, or payment retries ran out and the subscription was cancelled automatically. Before reading retention as a verdict on your product, separate departures using four signals the billing records already hold - which event fired, which status preceded it, whether a payment method was on file, and whether the decline was a hard decline - so you know who is worth contacting and who retries can never reach.
Three different causes land in the same canceled record
A&A perspective
When retention drops, the first move is not to revisit the product. It is to split last month's canceled subscriptions into three causes: the customer chose to cancel, a free trial ended without a payment method on file, and payment retries hit their limit and the subscription was cancelled automatically. On the billing platform, all three are recorded with the same status and the same event. The point of separating them is not to guess at customer intent. It is to tell apart, before you act, the people who come back if you contact them, the people who do not, and the people automated recovery can never reach at all.
From the sources
Stripe's documentation on cancelling subscriptions states that "Subscriptions cancel automatically after up to eight unsuccessful attempts to bill the customer," and that the number of attempts is configurable in the Dashboard subscription settings. In other words, a payment-driven departure appears in your records as a cancellation without anyone deciding to cancel anything.
From the sources
The same page describes the cancellation event. customer.subscription.deleted is sent when you call the API to delete a subscription directly, and it is also sent when a subscription with cancel_at_period_end set to true reaches the end of its billing period. The event name alone does not tell you which of the two happened.
From the sources
Stripe's documentation on trials states that the same customer.subscription.deleted event is also sent "after a free trial ends without a payment method" — when the missing-payment-method end behaviour is set to cancel — and that the subscription moves to the canceled status.
A&A perspective
So three different events — the customer chose to leave, the trial failed to convert, the card did not go through — collapse into one event and one status. That is not a defect. The fact that the subscription has ended is equally true in all three cases, so for a billing platform it is the correct design. The problem is what happens when you put that record straight into the numerator of your retention rate: you get the number of people who did not find the product worth paying for, plus the number of people whose payment did not clear. That total can move up or down without telling you what to fix.
A&A perspective
To be clear up front, this article does not answer what share of departures is payment-driven. A&A has not measured that share, and the documentation referenced here does not state a general ratio either. What it can answer is a procedural question: can you separate the three causes using only the records you already have?
The retry count is not the number of times the card was actually charged
From the sources
Stripe's documentation on automated payment retries lists four conditions under which it does not retry: when "No payment methods are available," when the issuer returned a hard decline code, when the card is India-issued, and when the Stripe Connect account has been disconnected.
From the sources
On what happens after a hard decline, the same page is explicit. Retries continue to be scheduled and the attempt counter continues to increment, but "retries only execute after detecting a new payment method." It also states that "Unexecuted retries don't create a new Charge."
From the sources
Nine hard decline codes are named: incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level and transaction_not_allowed. They cover a wrong number, a lost or stolen card, a request for authentication, and a transaction the issuer does not permit.
A&A perspective
This is the part that is easy to miss while looking at a dashboard. A display reading "8 attempts, all failed" does not necessarily mean the card was presented eight times and refused eight times. If the card is registered as stolen, the only attempt that actually executed may have been the first one, with the rest accumulating as schedule entries. The counter is counting attempts that were planned, not attempts that were made.
A&A perspective
That difference maps directly onto a difference in action. A failure like insufficient funds may clear later, and waiting can genuinely recover it automatically. A hard decline will not clear by waiting. The only route back is for the customer to enter a new payment method, and that is a job for an email, not for a scheduler. If you only look at the retry count, those two situations look like the same "in recovery" state.
Hypothetical example
Consider a hypothetical case. Five subscriptions failed to bill at month end, and the dashboard shows the attempt counter rising on all five. Suppose three are insufficient funds and two are cards registered as lost. If you leave all five sitting in "recovery," the two will be cancelled automatically once the configured window expires, and both will be added to your churn count. If you had separated them, you could have asked those two customers to replace the payment method before the window closed. These are illustrative numbers, not an A&A or customer result.
| Recorded signal | How to count this departure | Next action, with its deadline |
|---|---|---|
| An update event arrived setting cancellation at period end | Customer cancellation. Count it as a verdict on the product | Ask why before the billing period ends; after that it cannot be resumed |
| A trial ended with no payment method and a cancellation event arrived | Unconverted trial. Count it separately from product verdicts | Check whether anything was sent at the three-days-out signal |
| Billing kept failing and the configured limit cancelled it automatically | Payment-driven departure. Do not count it as a product verdict | Ask the customer to update the payment method before cancellation |
| The decline was a hard decline and no retry actually executed | Payment-driven departure. Outside automated recovery | Do not wait for retries; only a new payment method restores it |
| The subscription is past due and service is still being delivered | Not yet counted as a departure. Unclassified | Decide the status and the number of days at which you stop; cost is still accruing |
Where a subscription lands after failed recovery is a setting you already chose
From the sources
Smart Retries reattempts the charge a specified number of times within a specified window. The available windows are 1 week, 2 weeks, 3 weeks, 1 month and 2 months, and the documentation states that "The recommended default setting is 8 tries within 2 weeks."
From the sources
Where the subscription goes after recovery fails is a choice between three settings: cancel the subscription; mark it unpaid, in which case invoices continue to be generated and stay in a draft state; or leave it past due, in which case invoices continue to be generated and the customer continues to be charged according to the retry settings. The documentation also notes that no further payment attempts are made after the final attempt, and that changing the settings only affects future retries.
A&A perspective
What often happens in a solo or small company is that nobody remembers choosing this setting. It is running on its default, and the shape of your churn records is determined by that default. If it is set to cancel, payment-driven departures are mixed into your cancellation count. If it is set to leave the subscription past due, they never appear in the cancellation count — but you may be continuing to serve a subscription that is not being paid for. Which is correct depends on the business. What is avoidable is not knowing which one you picked.
From the sources
On where the decision to start and stop service belongs, Stripe's cancellation documentation states that "Pausing payment collection doesn't affect the subscription status, which we recommend using as the trigger for starting or stopping service to your customer."
A&A perspective
A&A reads that sentence as a precondition for classification in a small AI service. If the decision to stop serving is not tied to the subscription status, a past-due subscription keeps incurring inference cost. An AI service is a product whose cost of goods keeps accruing for as long as you keep serving it. Having no rule for when to stop is not a records problem; it is a spending problem.
From the sources
Local payment methods such as direct debit are not retried automatically by default. Even when retries are enabled, each method has its own ceiling. The documentation's table gives ACH Direct Debit a maximum of 2 retries over 40 days for insufficient funds, SEPA Direct Debit a maximum of 2 retries over 30 days, and Australia BECS Direct Debit a maximum of 4 retries over 30 days.
A&A perspective
So "there are retries" is a statement about card payments. The window you can wait and the number of attempts both change with the payment method. When you build the classification table, it is safer to keep a column for the payment method. If you sell to overseas customers on direct debit, the same "in recovery" label carries a different deadline.
An unconverted trial either looks like churn or disappears from the count
From the sources
When a free trial ends without a payment method, the subscription becomes canceled if the end behaviour is set to cancel, and paused if it is set to pause. On the latter, Stripe's trial documentation states that "The subscription remains paused until explicitly resumed."
A&A perspective
From the observer's side, those two settings produce opposite appearances. If you chose cancel, people who used up the trial and never entered a payment method land in the same number as customers who deliberately cancelled. If you chose pause, those people appear in neither the churn count nor the retained count; they accumulate somewhere that nothing aggregates. An unconverted trial is a departure where you cannot tell whether the product did not fit or you simply never raised the subject of payment. Putting it in the same column as a cancellation means reading it as a verdict on the product.
From the sources
The approach of a trial's end is signalled by the customer.subscription.trial_will_end event. The same documentation states it is "Sent 3 days before the trial period ends," and that for trials shorter than three days it triggers immediately.
A&A perspective
Those three days are not time for classification. They are the last time available to create a situation that needs no classification. A&A reads this signal as the boundary between two different jobs: before it, reducing unconverted trials is a job of contacting people; after it, it is a job of recording what happened. If nothing was sent three days out, the unconverted trials that followed are better read as a shortfall in communication than as a verdict on the product.
A&A perspective
How to design the trial itself — what can be tried, where the usage ceiling sits, and which of the three end behaviours to choose — is outside this article. The existing article "Before you ship a free trial for your solo AI product: define the job and the usage ceiling" covers those decisions. This article is about reading the records that arrive under settings that are already running.
Subscriptions in a paid trial are already counted as retained customers
From the sources
According to Stripe's trial offer documentation, a subscription that contains only trial offers whose prices are all zero has the trialing status. If it has a regular price item, or the trial price is not zero, it is different: "the subscription status will be active, incomplete, or past_due." A paid trial requires a successful payment to begin, so it follows the same lifecycle as an ordinary subscription.
From the sources
The effect on reporting is stated on the same page. "Trial offers revenue isn't available in Billing Analytics," and while Stripe tracks trial revenue using the trialing status, paid trials use active, which means "Stripe considers trial revenue as regular subscription revenue."
A&A perspective
In practice this means the denominator of your retention rate is contaminated. A subscription that entered on a one-week discounted introductory price is counted from its first month exactly like an ordinary retained customer. If it does not renew the following month, it shows up as a customer who did not retain — but in fact that person never paid the standard price at all. Unless you decide up front whether such subscriptions belong in the denominator, you get a misreading in which retention falls fastest in the months you ran the most paid trials. Changing how you sell looks like the product getting worse.
From the sources
This trial offer mechanism is, however, labelled a public preview in the documentation. Using it requires specifying the preview API version and creating subscriptions in flexible billing mode, and the constraints listed include that it cannot be used from Checkout or Payment Links, and that the trial length cannot be modified after the subscription is created.
A&A perspective
A&A's reading is that it is too early to build your classification around a feature in public preview. What to take from this section is not whether to adopt the feature but the question behind it: of the subscriptions currently in your retention denominator, how many have never paid the standard price? That question can be answered on any billing platform.
Six lines to attach to each departure
From the sources
There is a constraint on where you can write. Stripe's cancellation documentation states that after a subscription is cancelled "you can no longer update the subscription except for its metadata and cancellation_details." It also states that "You can't reactivate a canceled subscription."
A&A perspective
So classification is not something you reconstruct from memory after the cancellation. It is a decision, made before it happens, about where each piece of information will be written. And the room to contact someone and have them come back also exists only before the cancellation. What remains afterwards is a correction to a record, not a customer.
A&A perspective
Make it possible to fill in these six lines every time a departure occurs. One: the subscription identifier. Two: the last observed status and the date it entered that status. Three: the name of the event that arrived immediately before it. Four: whether a payment method was on file, and if so whether the most recent decline was a hard decline. Five: whether this departure counts in the numerator of your retention rate, and if not, which tally it belongs to instead. Six: who will make contact by when — or, if you decided not to contact them, the reason. Five of the six lines can be read mechanically out of the billing records. Only line five requires judgement, and line six is not a judgement but a commitment.
A&A perspective
These six lines are not a substitute for a survey asking customers why they left. A survey returns only the answers of the people who reply; these six lines are filled in for every case. Asking for reasons is worth doing only for the cases that the six lines classify as a customer cancellation. Asking anyone else means requesting product feedback about a payment failure.
Hypothetical example
Here is a hypothetical filled-in example. Suppose a month produced seven departures, and after filling in the six lines you find two customer cancellations, four trials that ended without a payment method, and one that could not be recovered because of a hard decline. With that split, two people are worth talking to about the product, four cases point at revising the trial-end communication, and one person needs an individual message asking them to replace the payment method. The same seven cases divide into three different jobs. These are illustrative numbers, not an A&A or customer result.
A&A perspective
The table below puts the recorded signal, the classification and the next action on a single sheet. The action with a deadline sits in the right-hand column because some of those columns cannot be recovered once the subscription has been cancelled.
What this article does not decide, and the next step
A&A perspective
This article does not tell you what share of departures is payment-driven. It does not tell you what share is recoverable, nor how your retention rate will move once you separate them. A&A does not hold those numbers, and the documentation referenced here is Stripe writing about its own product — not an independent audit and not a market observation. What it does establish is a fact about how the platform behaves: the three causes can be separated using the records you already have, and here is how.
A&A perspective
If you are not on Stripe, the reasoning transfers; the field names do not. On whatever billing platform you use, find the equivalents of these five things first: the number of attempts and the window before automatic cancellation, the conditions under which a retry is not executed, where the subscription goes after recovery fails, the behaviour at trial end, and the places that remain writable after cancellation. Once those five are filled in, the six-line sheet can be built.
A&A perspective
At a small scale, classifying barely moves any number. If you have six departures a month, splitting them three ways still leaves six. What changes is which of those six people you contact. The value of classification is not precision in the retention rate; it is not mistaking one deadline-bearing action for another. By the same token, while the number of departures is small, none of this needs to be automated. There is a stage at which filling in six lines by hand is faster.
A&A perspective
Recovering a payment is not by itself evidence that a customer is satisfied. That the card went through means only that that month's invoice was collected. If, after separating out the payment-driven departures, the remaining customer cancellations turn out to be more numerous than you thought, that is where the product conversation starts. If the next step is revising plans and access, the existing article "Before adding a paid AI SaaS plan: match the pricing table to real access" covers aligning the unit you sell with what customers can actually use. If you want to see retention and acquisition as one continuous job, "AI-native GTM: a practical guide for solo founders and small teams" is the overall map.
A&A perspective
If you cannot tell from your records which of the three dominates in your own business, sorting out what your current records can and cannot show is what advisory is for; A&A's initial consultation is free. If you are at the stage of building the mechanism that fills in the six lines, that is not advice but scoped development. A consultation is never a prerequisite for development.
One record labelled canceled holds, by design, customer cancellations, unconverted trials and automatic cancellations caused by failed payments. Before reading retention as a verdict on your product, separate departures by the signals your records already hold - the event, the preceding status, whether a payment method existed, and the kind of decline - and fill in six lines for each one. Only the customer cancellations that remain after the split are material for thinking about the product.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Automate payment retries
Stripe · no date shown on page; continuously updated product documentation
Accessed 2026-09-29 - Configure trial offers on subscriptions
Stripe · no date shown on page; labelled public preview for the Trial Offer API
Accessed 2026-09-29 - Cancel subscriptions
Stripe · no date shown on page; continuously updated product documentation
Accessed 2026-09-29
AI-assisted editorial production
A&A uses AI for research, writing, translation and editorial checks. Source facts, our analysis and hypothetical examples are labeled separately.
Editorial check: 2026-09-29