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. It 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 making them click “pay” every time. Dunning is what 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, all qualify. It matters most once “a person checks failed payments in the dashboard” stops scaling, which usually happens somewhere past a few hundred active subscriptions.
You do not need a custom build if your subscriber count is small. That holds as long as your gateway’s own billing portal already covers your plan structure, Stripe Billing’s hosted retry logic, for instance. It becomes worth building once you need proration rules, usage-based tiers, or local pricing a generic portal cannot express. The same goes for dunning emails that need to match your product’s voice and timing, not a gateway’s default template.
How we build it
The plan model lives in your own database, usually PostgreSQL: tiers, seats, usage units, trial periods. 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, say a tier priced in Thai baht on a different cycle, we run billing cycles ourselves. The gateway’s only job then is moving the money. Every subscription event gets driven by a webhook and written to an audit trail before anything else happens: created, renewed, past due, canceled, reactivated. 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, then a retry attempt a few days later, then another email. Only after a defined number of failures does access actually change. Card-update links point to the gateway’s secure update page. 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 real ownership cost is keeping the plan model in your database in sync with what the gateway’s dashboard shows. That is why every state change goes through one webhook pipeline, not 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 are close to what we built for 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, and we quote those 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, like local-currency tiers, usage caps or 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 gets suspended, not deleted. The customer keeps their data and can reactivate by updating a card. That line is one we set with you up front, not one the system draws on its own.