Should we let customers pause their subscription?

Yes. The pause option belongs inside the cancellation flow as a retention tool rather than a feature offered to everyone. Cap it, for example twice a year at up to 60 days each, and it stays under control.

How to Build a Subscription and Recurring Billing System: Billing Rules, Card Expiry Warnings and Daily Reconciliation (With Real Costs and a 90-Day Roadmap)

The Opening: The Problem Is Not Collecting Money, It Is Not Knowing Who Did Not Pay

A health supplements client switched from one-off purchases to monthly subscriptions. Month one looked great: 320 subscribers, roughly US$15,000 in monthly revenue. In month four they called because the books did not reconcile — the admin panel showed 310 active subscribers, the bank showed 268 deposits. Of the missing 42, some had expired cards, some had insufficient credit, some had cancelled the mandate inside their bank's app, and the system had told nobody. Four months of silent leakage came to about US$6,500 — more than the development cost they had saved by skipping a proper system.

Subscription billing is never hard because of the first charge. It is hard because of charges two through twenty-four, and because of who finds out when one fails. This article breaks down the full plan for a recurring-billing system: how to choose between three approaches, what it really costs, five traps you will hit, and a 90-day roadmap.

When It Fits, and When It Does Not

Right time to build subscription billing	Not yet
Consumables with a stable replenishment cycle (supplements, pet food, coffee)	Irregular cycles, or repurchase intervals beyond six months
Services billed monthly (software, advisory, courses, gyms, memberships)	High-ticket items customers reprice every time
100-plus recurring customers already invoiced manually	Fewer than 30 recurring customers — a spreadsheet is faster
Tiered plans with upgrades and downgrades	A single plan you do not intend to change
You need trials, promo codes, and pause-subscription retention tools	Sectors where pre-authorised recurring charges are not permitted

Three Alternatives Compared

Option	Approach	Build cost	Ongoing cost	Strengths	Weaknesses
A. Payment gateway's built-in recurring billing	Use the recurring product from a local gateway; your site only creates and queries mandates	US$2,000–4,000	Processing fee around 2.7–3.0%	Fastest launch, best local card compatibility, e-invoicing already integrated	Rigid plan model; upgrades and proration must be calculated by you
B. Stripe Billing	Manage plans, trials, discounts and invoices through Stripe subscription objects	US$4,000–8,000	around 3.4% + a fixed fee on domestic cards, Billing priced separately	Complete plan model, built-in proration, mature retry logic	Higher fee, local tax invoicing needs separate integration, some local card types need testing
C. Custom subscription engine plus payment authorisation	You own the cycle, state machine and retries; the gateway only authorises and captures	US$8,000–16,000	Processing fee around 2.7–3.0%	Fully custom, supports usage-based and hybrid pricing	Highest build and maintenance cost; a wrong state machine means silent revenue loss

For most small businesses the right answer is A: launch on the gateway's built-in recurring product, then build the failed-renewal alerting and subscriber status dashboard yourself. Re-evaluate B or C once you pass roughly 1,000 subscribers or your plan structure gets complicated.

The Full Process

Phase 1 | Billing rules definition (1–2 weeks): pin the plan table down in Notion or a spreadsheet — plan name, cycle, amount, trial days, upgrade and downgrade rules, refund policy, pause rules. Deliverable: a billing rules table plus a state machine diagram (trialing, active, past due, paused, cancelled, terminated). Skip this and you will rewrite later.
Phase 2 | Payments and invoicing integration (2–3 weeks): integrate the gateway's recurring billing API, create mandates, handle webhooks, wire automated invoicing each cycle. Deliverable: a staging environment that completes authorise, first charge, next charge, failure and retry end to end.
Phase 3 | Admin and notifications (2–3 weeks): subscriber list, status filters, failed-renewal queue, manual retry, and a customer-facing "my subscription" page for updating cards, pausing and cancelling. Notifications over email plus a messaging channel. Deliverable: staff can operate it, customers can self-serve.
Phase 4 | Reconciliation and reporting (1–2 weeks): a daily reconciliation job comparing expected charges, gateway captures and bank deposits, with alerts on any gap. Reporting on MRR, churn and renewal success rate. Deliverable: reconciliation report plus a three-metric dashboard.

Suggested tools: Figma for admin wireframes, Notion for the billing rules table, a local gateway for payments and invoicing, a messaging API for notifications, and Sentry for charge-failure alerting.

Real Cost Breakdown

Build (Option A): US$2,000–4,000, roughly 60–120 engineer-hours, covering gateway integration, admin panel and customer self-service.
E-invoicing: platform fee around US$15–50 per month plus a small per-document charge.
Processing fees: around 2.7–3.0% on domestic recurring card payments. At US$15,000 monthly revenue that is US$400–450 a month.
Notifications: messaging or SMS per notification. Failed-renewal alerts are not optional spend.
Hidden cost one: card refresh. Cards expire on roughly a three-year cycle, so about a third of your subscribers need a new card each year. Without a 30-day expiry warning that becomes straight churn. Budget US$600–1,300 to build it.
Hidden cost two: support load. Subscriptions generate two to three times the support volume of one-off sales — pause requests, date changes, double-charge queries. Roughly 0.3 FTE per 500 subscribers.
Hidden cost three: refunds and disputes. Recurring charges attract a higher dispute rate than ordinary transactions; each dispute costs roughly US$10–25 in staff time plus fees.

Reality vs What Clients Imagine

Imagined: once payments are integrated, charges just happen. Reality: charges fail, more often than you expect — insufficient credit, expired cards, issuer risk rules, customer-side mandate cancellation. A subscription system without retry and alerting is a leaking bucket.
Imagined: hide the cancel button and churn goes down. Reality: a buried cancel flow converts churn into chargebacks and complaints, and a high dispute rate can put your merchant account at risk. Make it clear, then insert a "pause for one month" option inside the cancel flow and you will recover a share.
Imagined: MRR equals subscribers times price. Reality: usable MRR excludes past-due accounts, paused accounts and subscribers whose cards expire this month without a refresh. Those three commonly account for 8–15% in a mature subscription business.

Five Traps and How to Avoid Them

Trap 1: no state machine. Managing subscriptions with an is_active boolean means that three months later nobody knows what "paused but prepaid" is. Fix: draw six states and every transition condition before writing code, and store them as a database enum.
Trap 2: non-idempotent webhooks. Gateways re-send notifications; the same charge gets recorded twice and the ledger rots. Fix: use the gateway transaction ID as a unique key and return 200 on duplicates without reprocessing.
Trap 3: no card expiry warning. This is the single largest source of silent revenue loss. Fix: record card expiry month at authorisation and send update prompts 30 days and 7 days out, with a one-click update link.
Trap 4: brutal retry strategy. Five attempts on the failure day gets you flagged by the issuer. Fix: retry on day 1, day 3 and day 7; after three failures move to past due and hand off to support (see Stripe's smart retry design principles).
Trap 5: upgrades without proration. A customer moving mid-cycle from a lower to a higher tier will complain whether you charge the full amount or nothing. Fix: pin the rule in the billing rules table and show the exact prorated amount on the self-service page before confirmation.

Success Metrics and 90-Day Roadmap

Days 1–30: billing rules table and state machine complete, recurring payments and invoicing integrated, one full cycle including failure and retry passing in staging. Metric: 100% of test cases passing.
Days 31–60: admin panel and customer self-service live, first 50 subscribers migrated (pick loyal customers), card expiry warnings and failure alerts switched on. Metric: renewal success rate at or above 92%.
Days 61–90: full migration of existing subscribers, daily reconciliation job and MRR/churn dashboard live. Metric: gap between expected and banked revenue under 0.5%, monthly churn at or below 5%.

Decision Checklist

☐ I have 100 or more recurring customers
☐ My product or service has a stable consumption cycle
☐ I can already write out the full plan table (name, cycle, amount)
☐ I have decided whether trials are paid and at what price
☐ I know what happens when a customer wants to pause
☐ I know how upgrade and downgrade differences are calculated
☐ Someone can review the failed-renewal queue daily
☐ My refund policy is written down and published
☐ I need an invoice issued automatically each cycle
☐ I need a page where customers update their own card
☐ I need live MRR and churn figures
☐ I accept processing fees of roughly 3% of revenue
☐ I am prepared to staff roughly 0.3 FTE of support per 500 subscribers

Nine or more ticked and the timing is right. Fewer than six and you should stay on manual invoicing for another quarter.

Frequently Asked Questions

Local gateway or Stripe?

It depends on plan complexity and customer base. Predominantly domestic customers with a simple plan structure — one to three plans, few upgrades — favour the local gateway: lower fees, invoicing already integrated, best issuer compatibility. Many tiers, trials, proration and overseas customers favour Stripe Billing, where the development time saved usually outweighs the higher rate.

How many retries are reasonable after a failed charge?

Three, spread across day 1, day 3 and day 7 after failure. Repeated same-day retries get flagged as anomalous by issuer risk systems and reduce success rates. After three failures, move to past due, suspend service and notify support rather than retrying indefinitely.

A customer says they never agreed to recurring charges. Now what?

Your system must retain the authorisation record: timestamp, IP, plan details, amount, cycle, and the version of the consent screen the customer accepted. That is the only useful evidence in a chargeback dispute, and it must be designed into the schema up front — you cannot reconstruct it afterwards.

Should we let customers pause? Won't everyone pause?

Yes, and you should. In practice the pause option lives inside the cancellation flow as a tool for retaining people who were leaving anyway, not as a feature offered to everyone. Cap it — for example twice a year, maximum 60 days each — and it stays under control.

Next Step

ScriptWalker's subscription and recurring billing system package covers billing rules definition, payment and invoicing integration, subscriber admin and customer self-service, failed-renewal alerting and daily reconciliation. From US$4,000, standard delivery 8–10 weeks. If you are still on spreadsheets and manual invoicing, we also offer a two-week "subscription leakage audit" that tells you how much you are currently losing.