Subscriptions: the churn nobody chose.
A customer who wanted to stay but whose card expired is not a retention problem. It is a payments problem, and it is usually larger than the deliberate cancellations the product team is worrying about.
Involuntary churn hides inside the churn number
Most subscription businesses report one churn figure, which bundles customers who left with customers whose payment failed. The first is a product conversation. The second is a stored-credential conversation, and it responds to completely different interventions: network tokens, correct transaction flagging, and retry schedules tuned to why the payment actually failed.
What teams in saas & subscriptions face
Renewals fail silently
A card expires or is reissued and the next charge fails, often without anyone noticing until the customer has lapsed.
Cards get reissued constantly
Stored credentials decay. Without a refresh mechanism, every reissue is a future failed renewal.
Retries done badly hurt
A fixed retry schedule applied to every decline wastes attempts on failures that can never succeed and risks your scheme standing.
Issuers treat renewals as unexpected
A recurring charge that is not flagged as merchant-initiated can look anomalous to an issuer, and be declined accordingly.
Revenue reporting is murky
Without separating involuntary from voluntary churn, the business optimises the wrong thing.
How a payment moves here
Capture with consent
The first payment stores the credential and records the customer's agreement to be charged again, which is what the schemes require for later initiation.
Flag every renewal
Subsequent charges are submitted as merchant-initiated transactions referencing the original, so issuers see expected activity.
Keep the credential alive
Network tokens and credential updates, where the route supports them, survive reissue and expiry.
Classify failures
Each decline is categorised. Hard declines stop; soft declines go to a reason-specific schedule.
Report the truth
Renewal success, recovery rate and involuntary churn reported separately from customers who actually chose to leave.
Built for saas & subscriptions
Stored credentials, tokenized
Your systems hold a token and a customer reference; the sensitive value stays in the payment environment.
Merchant-initiated flagging
Scheme-required initiation indicators set on every subsequent charge, where supported on the acquiring route.
Network tokens
Where available, tokens remove a whole class of failure by surviving the card reissue and expiry that break stored credentials.
Reason-aware retries
Insufficient funds is retried on a schedule; a closed account is not retried at all, because it will never succeed.
Structured recovery
A defined sequence across retries, credential refresh and, where you want it, customer outreach.
Subscription lifecycle visibility
Created, active, past due, recovered, cancelled and expired, each with the events that caused the change.
Payment links for recovery
When automated recovery runs out, a link lets a customer fix their payment without an integration change or a phone call.
What tends to matter here
- Cards with stored credentials
- Network tokens where available
- Wallet-tokenized cards
- Bank-based recurring arrangements where supported
Availability depends on merchant category, jurisdiction, underwriting and the applicable payment or acquiring partner.
Sector-specific considerations
- Consent to recurring charges must be recorded at capture; it is a scheme requirement, not a formality.
- Retry governance matters: attempt limits and spacing protect your standing with the schemes.
- Authentication on the initial transaction follows the rules of the market in play, which affects how later charges are treated.
Flowa Pay provides the payment technology and orchestration layer. Acquiring, scheme settlement and regulated payment services are provided by licensed acquiring and payment partners under their own authorisations.
What experienced teams get right
The practical details that separate a payment stack that runs quietly from one that generates work every week.
- Separate involuntary from voluntary churn in reporting. They are different businesses problems with different owners.
- Dunning communications should follow the payment state, not a fixed calendar.
- Measure recovery rate explicitly; it is the clearest evidence that credential and retry work is paying for itself.
SaaS & subscriptionsSaaS & subscriptions questions
No. The credential is tokenized and stored in the payment environment, and you charge the token.
Where network tokens and credential updates are available on your route, the stored credential is refreshed rather than failing at the next renewal.
By decline reason, on a schedule matched to that reason, within attempt limits. Hard declines are never retried.
On some. Bank-based recurring arrangements depend on the rail and the partner, and are confirmed per merchant.
Solutions that serve saas & subscriptions
These are the parts of the platform that do the work in this sector. Each one is a full solution page.
Recurring payments
Subscription revenue is lost to failed renewals far more often than to cancellations. Recurring support is built around keeping stored credentials alive and recovering the ones that fail.
Explore →Authorization optimisation
A meaningful share of declines are not the issuer refusing the customer. They are avoidable: stale credentials, thin data, the wrong route, a retry at the wrong moment.
Explore →Payment links
Create a link, send it, get paid. Payment links give teams a way to take a real, reconciled payment with no development work at all.
Explore →Reporting & analytics
Approval, decline, volume and cost broken out by every dimension that matters, with transaction search and exports that finance can actually use.
Explore →Ready to build for saas & subscriptions?
Tell us about your flows and volumes and we will scope the routes and methods that fit.