Stripe Billing retention features: what's built in and what isn't

Stripe Billing ships with more retention tooling than many teams realize. Before you build or buy anything, it is worth knowing exactly what is already in your account, what each piece does, and where it stops.

This guide maps the built-in features from Stripe’s documentation (accessed November 2026), then lists the gaps. We already covered retry timing in depth in how Stripe Smart Retries work, so this article stays at the level of the whole toolkit.

The built-in toolkit at a glance

Area	What Stripe provides	Where to read more
Retries	Smart Retries or a custom schedule	Smart Retries
Customer emails	Failed payment, expiring card and reminder emails	Customer emails
Workflows	No-code automations (trigger, filters, actions)	Automations
Card updates	Card account updater with the networks	Revenue recovery
Cancellation	Customer portal cancellation page, reasons, retention coupon	Cancellation page
Targeted offers	Retention rules (private preview)	Retention rules
Plan changes	Portal plan switching, downgrades at period end	Configure the portal
Pause	Pause a subscription or pause collection	Pause subscriptions
Reporting	Billing analytics, retention performance, benchmarking	Analytics

Failed payments: what is built in

Retries

Smart Retries picks retry times with a model; Stripe recommends 8 tries within 2 weeks. You can switch to a custom schedule instead. Stripe will not retry after certain hard declines until a new payment method is collected. Details and settings are in our Smart Retries guide.

Customer emails

Stripe can send the customer an email after each failed payment, an email one month before a saved card expires, and reminders for unpaid invoices and payments waiting for confirmation (for example, an authentication step). These are switched on in the Billing settings (customer emails).

Automations

Automations are no-code workflows built from a trigger (such as a failed subscription payment, an overdue invoice or a cancellation), optional filters and actions (such as setting a custom retry policy, marking a subscription unpaid, marking an invoice uncollectible or emailing your team) (automations). They are useful for treating segments differently, for example a longer grace period for large accounts.

Card account updater

Stripe works with card networks to update saved card details when a customer receives a new card number. This quietly prevents a share of failures that would otherwise happen at expiry. It does not help when the bank account behind the card is empty or the customer cancelled the card on purpose. See network tokens and card account updater.

Cancellations: what is built in

The portal cancellation page

The customer portal can show a cancellation page with a fixed list of reasons (too expensive, missing features, switched to an alternative, no longer needed, and others, plus free text). The answer is stored on the subscription in cancellation_details.feedback and visible in the Dashboard, in Sigma and in the customer.subscription.updated webhook (cancellation page).

Retention coupon and retention rules

You can attach one retention coupon to the portal’s cancellation step. It is off by default. Retention rules, in private preview at the time of writing, let you target offers by conditions such as cancellation reason, tenure and spend; turning them on disables the single retention coupon (retention rules).

Plan switching and downgrades

If you enable subscription updates in the portal, customers can switch plans themselves. A “manage downgrades” option can schedule a downgrade for the end of the billing period instead of applying it immediately; Stripe implements this with a subscription schedule, and it only works between prices of the same product (configure the portal).

Pause

Stripe documents two mechanisms. A full pause suspends service and invoicing. Pausing collection (pause_collection) keeps the subscription in its current status and handles invoices created during the pause by keeping them as drafts, marking them uncollectible or voiding them (pause subscriptions). Our Stripe pause guide compares them.

Reporting: what is built in

Billing analytics gives you MRR, an MRR roll-forward (new, reactivation, expansion, contraction, churn, FX adjustment), churned revenue, subscriber churn and a retention-by-cohort view. A few definitions are worth knowing before you compare Stripe’s numbers with your own:

• Subscriber churn rate is measured over a rolling 30-day window, and its denominator includes subscribers active at the start plus new subscribers during the window.
• Churned revenue includes both voluntary churn and churn from failed payments.
• You can configure whether discounts are excluded from MRR and whether a cancellation counts as churn immediately or at period end.

Retention performance reports on cancellations through the portal only, and counts a save only if the customer stays subscribed at least 7 days after accepting an offer. Cancellations made through your support team or your own app are not in it.

What isn’t built in

This is where you either write code, accept the limitation or use a separate tool. We list what we could not find in Stripe’s Billing documentation; if Stripe adds something, its docs win.

Recovery messages that match the decline

Stripe’s failed payment email goes out after each failed attempt. We found no documented option to vary its message by decline reason, yet an insufficient funds decline and an expired card need different words: one asks the customer to wait or switch cards, the other to enter a new card. If you want a message per decline reason or per segment, you send it yourself from invoice.payment_failed webhook events.

An offer per cancel reason, without the preview

Without retention rules, the portal has one coupon for everyone. “Not using it enough” is usually better served by a pause; “too expensive” by a downgrade. Matching offers to reasons is the core of a good cancel flow.

A cancel flow in your own app

The portal is a Stripe-hosted page. If customers cancel inside your web app, a desktop app or a mobile app, you build the screens and call the Subscriptions API yourself, including the reasons, the offer logic and the “cancel now” button.

Win-back after the subscription ends

Once a subscription is cancelled, we found no built-in sequence that writes to the former customer at set intervals based on why they left. You keep the Customer object and the reason, but sending anything is up to you. See how to win back canceled subscribers on Stripe.

Risk scoring with your own data

Stripe sees payments. It does not see your product usage, your support tickets or the attributes you collect at signup, so it cannot tell you which of your customers look likely to churn, or which attributes go together with churn. That analysis needs your data joined with billing data; our guide to predicting churn with customer data shows the method.

One view across sources

If part of your revenue comes from the App Store, Google Play or another billing tool, Stripe’s analytics only show the Stripe part.

Is the built-in toolkit enough?

For many early-stage products, yes. A reasonable minimum setup:

1. Smart Retries on, with a deliberate end-of-retries action.
2. Failed payment and expiring card emails on.
3. Portal cancellation page on, with reasons collected.
4. Downgrades scheduled at period end if you have more than one plan.
5. A monthly look at churned revenue split between voluntary and failed payments.

You likely need more when cancellations happen inside your own app, when you want different offers per reason, when failed payments are a large share of churn, or when you want to act on customers before they reach the cancel button.

Doing this with NoChurn

NoChurn connects to Stripe in one click and adds what the list above leaves out. For failed payments, it runs smart retries timed to the decline reason and payday, sends AI-written recovery emails you can review, and links to a hosted card update page. For cancellations, it runs cancel flows with reasons and one offer per reason (discount, pause or plan change), with a one-click cancel always visible, as a hosted modal or through a headless API in your own app. After a cancellation it sends win-back emails at day 30, 60 and 90 based on the reason. It also gives each customer a churn score from 0 to 100 at signup and on every change, and accepts your own data by API to show churn drivers (correlation, not causation).

Every feature is on every plan, priced only by MRR, and never as a share of recovered revenue. See pricing.