Written by Josh @ Gleam
Six switches, mostly off by default
in a typical Stripe setup
Most of these are a settings change, not an engineering project.
Most subscription businesses stop at the basics with Stripe: a price object, a checkout flow, a webhook handler, done. That covers taking payment. It doesn't cover the parts of running a recurring business that actually separate a healthy subscription base from a leaky one: self-serve account management, failed payment recovery, international pricing, and tax compliance.
Stripe has shipped real, mature answers to all of these. Most teams just haven't turned them on. Here are six worth checking today, in order of how much they typically matter for an existing subscription business.
Six features, at a glance:
A lot of engineering time gets spent on a settings page that lets customers update a card, change plans, or cancel. Stripe's Customer Portal is a pre-built, Stripe-hosted version of exactly that page, and it's usually a better one than a small team would build in-house: it's secure by default, handles proration correctly, and stays current with Stripe's own billing logic without you maintaining it.
The part worth actually configuring, not just enabling, is the cancellation flow. Instead of a bare "cancel" button, the Portal lets you insert a pause option, a discount offer, or a short feedback prompt before the cancellation completes. That single setting is one of the cheaper churn-reduction levers available: it costs nothing to build and it sits directly in the path of every customer who was about to leave anyway.
If your prices are set in US dollars but a meaningful share of signups come from Europe, Latin America, or Asia, foreign exchange friction at checkout is quietly costing you conversions. Adaptive Pricing shows your subscription price in the customer's local currency, using localized price points rather than a raw currency conversion, and Stripe holds that renewal amount stable in the local currency across billing cycles so subscribers don't see their bill fluctuate month to month.
The numbers here aren't marketing fluff. In Stripe's own test across 1.5 million subscription checkout sessions, offering Adaptive Pricing at signup increased conversion by 4.7% on average and lifted downstream LTV per session by 5.4%, with some businesses seeing gains well above that. Customers who pay in their own currency also tend to retain better than those billed in your default currency, which matters more than the initial conversion bump if you're tracking MRR and ARR rather than just signups.
Failed recurring payments, not cancellations, are the largest source of involuntary churn for most subscription businesses. A card expires, a bank flags an unfamiliar charge, a balance is briefly short: none of that means the customer wanted to leave, but a naive "retry every three days" policy recovers far fewer of them than it could.
Smart Retries, under Billing Settings > Revenue Recovery, uses Stripe's models to pick the retry timing most likely to succeed for that specific card and region rather than a fixed schedule. Stripe reports an average recovery rate around 55% for failed payments under Smart Retries, though real-world results vary by business type and what else you're running alongside it. Two settings are worth pairing with it: automated dunning emails so customers know a charge failed before you cancel them for it, and Card Account Updater, which refreshes card numbers and expiration dates with the issuing bank before an old card actually bounces. A payment that fails and eventually recovers is exactly the kind of movement worth tracking separately from a real cancellation; conflating the two is one of the reasons a single "revenue dropped" number from Stripe's dashboard isn't the full picture.
"Three months at half price, then full price, then annual renewal" is a completely reasonable pricing idea and a genuinely painful thing to hand-build. Teams that try usually end up with custom database tables tracking which phase every subscription is in, plus cron jobs to move them along, plus edge cases around proration that take weeks to get right.
Subscription Schedules handle this natively. You define a sequence of phases, each with its own price, quantity, or trial length, and Stripe manages the transitions and proration in the background. No cron job checks whether a promo period ended; Stripe already knows, because the schedule said so when it was created. If your business runs intro pricing, seasonal plans, or any multi-step onboarding offer, this is very likely cheaper to build on Subscription Schedules than on custom logic, and it removes an entire category of "did the transition actually fire" bugs.
Sales tax and VAT compliance for a software business is genuinely hard to get right by hand, and it's easy to cross a tax obligation (a "nexus") in a state or country without noticing, especially once you have customers spread across a few dozen jurisdictions. Waiting for a compliance question to force the issue is the expensive way to find out.
Stripe Tax detects a customer's location at checkout, calculates the applicable VAT, GST, or sales tax, and appends it to the invoice automatically. For B2B customers, it also collects and validates tax IDs like EU VAT numbers, which lets those transactions be reverse-charged correctly instead of manually tracked in a spreadsheet somewhere. Turning this on when you're small is a much smaller lift than retrofitting it once you have years of transaction history to reconcile.
This one is for whoever is actually integrating with Stripe's API, not a dashboard toggle. A common bug in subscription checkout flows: a customer on a slow connection double-taps the "subscribe" button, or a request times out and your own retry logic fires it again, and now there are two subscriptions or two charges instead of one.
An idempotency key, a unique value passed in the request header on creation calls, fixes this at the API level. If Stripe sees a request with a key it's already processed, it returns the result of the original request instead of creating a second one. It costs one line of code per write call and it closes off an entire class of duplicate-charge support tickets, which makes it one of the highest-leverage-per-minute changes on this list for whoever owns the integration.
Do I need Stripe's Customer Portal if I already built my own account settings page? Not strictly, but it's worth comparing what it costs you to maintain proration logic, plan-change edge cases, and PCI-relevant card update flows yourself against a hosted page Stripe already keeps current. Most teams find the Portal is at least as capable and considerably less work to maintain.
Does Adaptive Pricing change what I actually collect per customer? No. It changes the currency and localized price point shown at checkout; your Stripe balance still settles in your platform currency. What changes is conversion and retention among international customers who'd otherwise see an unfamiliar, unlocalized USD price.
Is Smart Retries enough on its own to fix failed payments?
It meaningfully reduces involuntary churn, but it works best paired with dunning emails and Card Account Updater. None of the three replaces knowing, in your own data, how much MRR is being lost to payment_failed events specifically versus real cancellations.
How many phases can a Subscription Schedule have? Stripe supports multiple sequential phases per schedule, each independently priced, so most promo-then-standard or trial-then-paid flows fit comfortably within a single schedule without custom logic.
None of these six features tell you whether your recurring revenue is actually healthy month over month, though. That's a layer above what Stripe's dashboard is built to show: real MRR normalized from subscription prices, movements classified as new, expansion, contraction, or churn rather than lumped into one number, and a forecast for where you're headed next. Gleam Revenue computes all of that directly from your Stripe data, refreshed daily. Start your free trial →