8.3% of Subscription Revenue Dies at "Card Expired": How to Build a Recurring Billing System — Tokenisation, Retry Logic and Dunning

A B2B subscription tool company came to us this March with an opening line of "we keep losing subscribers — maybe the product isn't good enough." We pulled 14 months of billing records. Ending count: 1,240 paying subscribers, averaging 58 new and 42 churned per month. What surprised the founder was the composition of that churn: of the 42, only 11 clicked cancel. The other 31 never cancelled at all — their cards simply failed: 17 expired cards, 9 insufficient funds, 5 blocked by issuer risk rules. That works out to roughly 8.3% of recurring revenue lost each month, not to a competitor, but to a payment failure nobody was handling. Nothing was broken. Nobody had ever written the code for "what happens after the charge declines."

When This Is Worth Building — And When It Isn't

Invest in a full recurring billing system if:

• You have 300+ recurring paying customers and expect that to double within 12 months
• Your revenue is cyclical: monthly, annual, quarterly, plan upgrades, seat add-ons
• You currently track "who should be charged this month and who failed" in a spreadsheet
• Average revenue per user exceeds NT$300/month, making recovery of a single failed charge worth the process
• You bill through both web and app entry points and need one shared subscription state

Don't spend the money yet if:

• You have fewer than 80 customers with no growth — create recurring mandates manually in the gateway console
• Your revenue is one-off purchases or project quotes with no cycle
• Your pricing still changes every two months — stabilise it first, or you'll rebuild the system immediately
• You only charge inside an iOS/Android app and won't open a web payment path — use platform in-app purchase; building your own would breach the rules

Alternatives Matrix

For most Taiwanese SMBs the working answer is: web billing through an ECPay or NewebPay recurring mandate, plus your own subscription state machine and dunning flow. Add platform in-app purchase only if the app has its own paywall — and have both sides write to one subscription table.

Full Process Breakdown (Phases, Time, Deliverables, Tools)

• Phase 1 — Billing model design (4 working days): define plans, billing cycles, trial periods, proration rules for upgrades and downgrades, and refund policy. Deliverables: billing rulebook plus state machine diagram. Tools: Figma for checkout wireframes, Notion for versioning the rulebook.
• Phase 2 — Card tokenisation and authorisation (6–10 working days): first authorisation, token storage (full card numbers never touch your database), 3-D Secure flow. Deliverables: working card-binding page and test report. Tools: ECPay/NewebPay sandbox, ngrok for local webhook debugging.
• Phase 3 — Subscription state machine and scheduled charging (8–14 working days): implement active / past_due / grace / canceled / expired states with transition rules, plus a daily charging batch. Deliverables: state machine test matrix. Tools: Laravel Cashier or a bespoke layer, Laravel Horizon for queue monitoring.
• Phase 4 — Dunning and recovery flow (5–8 working days): retry schedule, one-click card update link, three-stage reminders, and feature downgrade during the grace period instead of a hard cut-off. Deliverables: dunning message templates (email + LINE) and a sequence diagram.
• Phase 5 — Invoicing, reconciliation and support tooling (5–8 working days): integrate the Ministry of Finance e-invoice platform, build settlement reports, and give support a per-charge history view. Deliverables: reconciliation reports and support console. Tools: Metabase or an in-house reporting screen.

Real Cost and Hours (Three Budget Tiers)

Hidden costs that routinely get missed:

• Card processing fees of 2.2%–2.8% — at NT$500,000 monthly volume that's NT$11,000–14,000 straight off gross margin
• E-invoice value-added provider: NT$500–1,500/month plus NT$0.3–1 per invoice issued
• SMS reminders on failed charges at NT$0.8–1.2 each — roughly NT$300–600/month for 1,000 subscribers
• Reconciliation labour: even fully automated, expect 2–4 hours a month on disputes and refunds
• Gateway reserve and settlement terms (commonly T+7 to T+15) materially change your cash-flow model
• ScriptWalker service: Subscription and Recurring Billing System Build, from NT$96,000 (card authorisation, subscription state machine, retry logic with three-stage dunning, e-invoice integration)

Implementation Reality vs Client Expectation

• Clients assume: the gateway has a "recurring" feature, so this is a quick integration. Reality: the gateway handles "charge this card monthly." How to price an upgrade mid-cycle, how to refund, whether to suspend during grace — that's all your business logic, and it usually accounts for over 60% of total hours.
• Clients assume: a failed charge means the customer wants out. Reality: expired cards plus temporary insufficient funds usually make up more than half of failures, and both are recoverable. A three-step retry ladder (day 1, day 3, day 7) paired with a card-update link recovers an average of 52% of failed charges in the accounts we run.
• Clients assume: cutting access immediately on failure is the fair thing to do. Reality: an instant cut-off converts recoverable customers into permanent churn. Give a 7–14 day grace period with degraded functionality (read-only, rate-limited) rather than a full lockout.
• Clients assume: storing card numbers in our own database is simpler. Reality: storing raw card data pulls you into PCI DSS scope, which no SMB should take on. Always use the gateway's token; the card number never enters your database.
• Clients assume: once the system is live it's stable. Reality: the real work starts at launch — every month you review failure rate, recovery rate and downgrade rate, then tune the retry schedule and reminder copy accordingly.

Common Traps and How to Avoid Them

• Trap 1: billing logic lives inside a cron script with no state machine. Fix: draw the active / past_due / grace / canceled / expired transition map first, code to the map, and write every state change to an audit log.
• Trap 2: the charging batch isn't idempotent, so a rerun double-charges. Fix: make "subscription ID + billing period" a unique key so only one successful charge can exist per period.
• Trap 3: webhooks only handle success, not failures or late notifications. Fix: persist every raw webhook payload before processing, and implement signature verification plus tolerance for redelivery.
• Trap 4: upgrades skip proration and the customer gets billed a full month twice. Fix: credit remaining days at the moment of upgrade and show the exact amount to be charged on the confirmation screen.
• Trap 5: data gets deleted the instant a subscription is cancelled. Fix: cancellation only sets an end date; retain data for 30–90 days afterwards — that window has the highest win-back rate.
• Trap 6: invoices are issued before the charge succeeds. Fix: bind invoice issuance to the charge-succeeded event and run allowances or voids on refunds, so month-end accounting reconciles.
• Trap 7: dunning is email-only. Fix: email open rates are limited in the Taiwanese market — send the second reminder via LINE Official Account or SMS, with a one-click card update link attached.

Success Metrics and the First 90 Days

• Days 1–30: stabilise charging. Targets — first-attempt authorisation rate ≥ 92%, zero double-charge incidents, zero missed webhooks. Reconcile batch counts against the gateway console daily.
• Days 31–60: switch on recovery. Targets — failed-charge recovery rate ≥ 40%, involuntary churn down from 70% of total churn to under 45%. A/B test reminder copy and send timing.
• Days 61–90: optimise retention. Targets — monthly churn down by 2+ percentage points, annual plans ≥ 25% of the base, subscription-related support tickets down 50%. Introduce pre-cancellation save offers (pause subscription, downgrade plan).

Decision Checklist

• ☐ We have 300 or more recurring paying customers
• ☐ We track who to bill each month manually or in a spreadsheet
• ☐ We can't say how many charges failed last month
• ☐ There is no automatic retry after a failed charge
• ☐ No reminder is sent to the customer after a failure
• ☐ Customers must call or email support to update a card
• ☐ Upgrade price differences are calculated by hand
• ☐ Invoices are issued as a manual batch at month end
• ☐ Support can't look up a customer's charge history themselves
• ☐ Cancellations require manual handling by support
• ☐ We don't track involuntary vs voluntary churn separately
• ☐ We expect subscriber count to more than double in 12 months
• ☐ We bill on both web and app, and the states don't sync

Five or more checked: schedule this for next quarter. Eight or more: you are losing recoverable revenue every single month.

Frequently Asked Questions

Gateway recurring mandate or your own scheduled charging — which should we pick?

It comes down to whether you need control over retry timing. A gateway mandate runs on their schedule with a fixed retry policy. Your own scheduler charges a stored token on demand, letting you set a day 1 / day 3 / day 7 retry ladder and your own dunning rhythm — at the cost of 60–100 extra development hours. Under 300 subscribers, start with the mandate; move to your own scheduler as you grow. Note that the switch requires customers to re-authorise their cards, so plan it early.

How many retries after a failed charge, and how far apart?

Three is the sweet spot in practice: day 1, day 3 and day 7 after the failure. Marginal recovery drops off sharply beyond three attempts, and some issuers treat frequent re-presentment as anomalous. Pair every retry with a notification, and switch to LINE or SMS from the second attempt onward — that outperforms simply adding more retries.

Our app has a paywall — must we use App Store in-app purchase?

If what you unlock is a digital feature inside the app, platform review rules generally require in-app purchase, at 15%–30% commission. A workable pattern is to keep your own web checkout as the primary payment path, avoid steering users to external payment inside the app, and have both sides share one subscription state table. Always confirm against the current review guidelines before submitting.

How do we get ahead of cards that are about to expire?

Store the expiry month and send update reminders 30 days and 7 days before it, each with a one-click card update link. Some acquirers offer an account updater service that reduces interruptions when cards are reissued — worth asking about during contract negotiation. This single measure typically removes about a third of involuntary churn.

Want to Know How Much Recoverable Subscription Revenue You're Losing?

We offer a one-off Subscription Billing Health Check. You get a report covering first-attempt authorisation rate, failure reason breakdown, share of involuntary churn, and the specific gaps in your recovery flow — with a prioritised list you can drop straight into your development schedule.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p