Subscription billing that retries failed cards
before a customer notices they lapsed
Recurring revenue dies quietly: a card expires, the charge fails once, and the customer churns without ever deciding to leave. We build the billing logic that retries a failed charge on a schedule, emails the customer before and during the retry window, and only cancels access after a real, final failure, not the first one.
What it is
Subscription billing is the part of a product that charges a customer repeatedly without asking them to click “pay” every time, and dunning is the process that happens when one of those charges fails. A card expires, a bank flags an unfamiliar recurring charge, a wallet runs low: all of this is routine, and a billing system that treats the first failure as a cancellation loses customers who never actually decided to leave. We build the plan model, the recurring charge logic, and the retry-and-notify sequence together, because a billing system without dunning is only half built.
When you need it (and when you do not)
You need this once you charge the same customer more than once for the same subscription: a SaaS product, a membership, a box subscription, a managed service billed monthly. It matters most once your subscriber count is large enough that “a person checks failed payments in the dashboard” stops scaling, usually somewhere past a few hundred active subscriptions.
You do not need a custom build if your subscriber count is small and your gateway’s own billing portal (Stripe Billing’s hosted retry logic, for instance) already covers your plan structure. It becomes worth building when you need proration rules, usage-based tiers, or local pricing a generic billing portal cannot express, or when dunning emails need to match your product’s voice and timing rather than a gateway’s default template.
How we build it
The plan model (tiers, seats, usage units, trial periods) lives in your own database, usually PostgreSQL, so pricing logic is never locked entirely inside a third-party dashboard. Where the gateway’s native subscription object fits your pricing, we use it directly; where it does not (a tier priced in Thai baht with a different cycle than the gateway’s default, for example), we run billing cycles ourselves and only use the gateway to move money. Every subscription event, created, renewed, past due, canceled, reactivated, is driven by a webhook and written to an audit trail before anything else happens, so the subscription’s state is never just “whatever the gateway currently shows.”
The dunning sequence itself is a schedule, not a single retry: a failed charge triggers an email, a retry attempt a few days later, another email, and only after a defined number of failures does access actually change. Card-update links point to the gateway’s secure update page, so a customer can fix an expired card without us or you ever touching the new card number.
What to watch
Dunning timing is a real trade-off: too aggressive, and you annoy customers whose bank just had a routine hiccup; too lenient, and you carry non-paying accounts for weeks. We set the schedule with you rather than defaulting to a generic one. Running cost is mostly the gateway’s transaction fees plus a modest amount of email sending; the main ownership cost is keeping the plan model in your database synchronized with whatever the gateway’s dashboard shows, which is why every state change goes through one webhook pipeline rather than two.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| MVP | from $1,800 | One plan structure, one gateway, retry-and-email dunning sequence | 2 to 4 weeks |
| Production | from $4,500 | Multiple plan tiers, proration, usage-based billing, admin dashboard for subscription health | 5 to 8 weeks |
Related
Pair this with invoicing and receipts so every successful charge produces a document automatically, and with payment gateway integration if the underlying checkout is not built yet. For marketplaces splitting recurring revenue between sellers, see split payments and payouts. This sits inside the development and e-commerce services. The billing and audit-trail patterns here run inside the ProBay AI agent team and the factory ERP recovery case studies.
Ready to stop losing subscribers to expired cards? Get in touch and tell us your current plan structure.
FAQ
How much does subscription billing with dunning cost?
From $1,800 for a standard tiered plan on one gateway with a retry and email schedule; usage-based billing or multiple currencies add time, quoted after a short scoping call.
How long does it take to build?
2 to 4 weeks, depending on how many plan types and proration rules you need.
Do you build this on Stripe Billing or from scratch?
We use Stripe Billing or a comparable gateway subscription API where it fits your pricing model; for pricing logic a gateway cannot express (local-currency tiers, usage caps, bundled seats), we add a billing ledger on top in Python/FastAPI and PostgreSQL.
Who owns the billing code and data?
You. The ledger lives in your database, the gateway account is yours, and the code is in your repository.
What happens after a customer's card keeps failing?
A defined grace period runs out and access is suspended, not deleted; the customer keeps their data and can reactivate by updating a card, which is a decision we set with you up front, not one the system makes silently.