Subscription Billing System Guide: Plan Design, Recurring Charges, Failed-Payment Retries, Prorated Upgrades and Downgrades, Cancellation and Invoicing

“We want to switch the product to a subscription, just charge automatically every month.” That sentence often opens a project, and it is often where the underestimating begins. Soon after launch you run into questions: what happens when a customer’s card expires? Should a failed charge cut off access immediately? A customer upgrades from the basic plan to the advanced plan mid-month; how much should this month cost? A customer cancels; should the unused days be refunded? Who should the invoice be issued to, and for how much? Almost all of the real workload of a subscription billing system lies in these “exceptions.”

The upside of a subscription model is stable, predictable revenue and a customer relationship that lasts longer than a one-time sale. But that stability rests on a reliable billing mechanism: every charge has to be correct, every status change has to be recorded, and every invoice has to match the money actually received.

What follows covers, in order, how to design plans and billing cycles, how recurring charges work, how to retry failed charges and follow up on them, the rules for upgrades, downgrades and proration, handling cancellations and refunds, issuing e-invoices, and finally a rules decision table to fill in before development.

Separate the core subscription concepts first

Several concepts in a subscription system are often lumped together. Separate them before development:

• Plan: what you sell, which features or benefits it includes, and its billing cycle.
• Subscription: a particular customer on a particular plan, when it started, its current status, and when it next renews.
• Payment method: the saved card or other payment channel. It belongs to the customer, not to the subscription.
• Bill (invoice): the itemized amount due each period, including plan fees, add-ons, discounts, and adjustments.
• Payment record: the result of actually requesting payment from the payment provider, success or failure, and the reason for failure.
• E-invoice: the electronic invoice issued against payment actually received.

The most common design mistake is stuffing all of these into a single “order” table. Each renewal then copies an order, a failed charge can only change an order status, and at upgrade time nobody knows which record to change. Separate subscriptions, bills, and payments, and every complex scenario downstream becomes manageable.

Plan design: the system must withstand future change

Plan design is a business decision, but its structure directly determines how complex the system becomes. Common billing models include:

• Flat rate: one fixed price per period; the simplest.
• Per-unit billing: billed by number of users, accounts, or locations; the fee must adjust when the quantity changes.
• Usage-based billing: settled at the end of the period based on actual usage, such as messages sent or storage used.
• Base fee plus overage: the plan includes a set allowance, and anything beyond it is billed separately.
• Add-ons: features or services purchased on top of the main plan.

A few design principles:

Plans need versions. Plan contents and prices will change sooner or later, but customers already on the old plan usually continue on the original terms or get a transition period. If you edit the plan data directly, old customers’ bills change along with it. The right approach is to add a new plan version, keep existing subscriptions pointing at the original version, and put new customers on the new one.

Decide the billing cycle and billing date up front. Do all customers get billed on one fixed day each month, or on the anniversary of their own subscription start? The first makes reconciliation easier, but a new customer’s first period needs prorating; the second feels intuitive to customers, but someone is being charged every single day. Both work. What matters is deciding at the start and applying it consistently.

A trial is a status of the subscription, not a separate product. When the trial ends, whether it converts to paid automatically, requires a card to be saved, or simply expires, each behavior has to be defined in advance.

How recurring charges work

The common approach in Taiwan is to use a payment provider’s recurring card charge or card token feature: on the first payment, the customer enters their card number, the provider stores the card details and returns a token, and from then on your system uses that token to request payment on each billing date. Your system should not store full card numbers itself. That involves strict data security requirements, and leaving it to the payment provider is the safest approach.

A recurring charge roughly runs like this:

1. A scheduled job finds the subscriptions due for renewal on the billing date.
2. It generates a bill based on the plan and any changes during the period.
3. It requests payment from the provider using the saved payment method.
4. It receives the provider’s result (a synchronous response or an asynchronous notification).
5. On success, it extends the subscription period and issues an invoice; on failure, it moves into the retry and follow-up flow.

The thing to watch most closely in this flow is idempotency: the same bill must never be charged twice. A scheduled job may rerun, the provider’s notification may be resent, and a network call may time out and retry. The system has to check, bill by bill, whether this period has already been successfully charged, and lock the bill before requesting payment so concurrent processing cannot cause a double charge. For the details and pitfalls of payment integration, see Payment Gateway Integration in Taiwan.

Payment providers’ recurring features can also be used in two ways. In one, the provider charges automatically on the agreed cycle and tells you the result. In the other, the provider only stores the card, and your system decides when to charge and how much. The first is simple but offers limited flexibility for upgrades, downgrades, and proration; the second is flexible, but you are responsible for the charge schedule and retry logic.

Failed charges: retries, dunning, and grace periods

Failed charges are an everyday part of subscriptions. Causes include expired cards, insufficient credit limits, rejection by the bank’s risk controls, and cards reported lost. Handled well, most failures can be recovered; handled badly, customers get cut off without knowing why and simply leave.

A sensible failure-handling mechanism includes:

Distinguish failure reasons. Some failures may succeed on retry (for example, a temporarily insufficient limit), while others never will (for example, a card reported lost), in which case you should ask the customer to update their payment method right away. Factor the provider’s error codes into this decision.

Schedule retries. Retry several times over a period, with gradually longer intervals, rather than charging repeatedly on the same day. The number of retries and their spacing should be configurable settings.

Notify the customer at the same time. Send a notice on the first failure explaining the reason and providing a link to update the payment method. The link should go straight to the card update page, rather than making the customer log in and then search around.

Set a grace period. During retries the customer can usually keep using the service normally; only if payment still has not succeeded when the grace period ends does the subscription move to suspended or downgraded. The length of the grace period is a business decision, so the system must make it configurable.

Recovery should be automatic. Once a customer updates their card, the system should immediately charge any unpaid bills and, on success, restore service automatically, without support staff stepping in.

As a result, a subscription has at least these statuses: trialing, active, past due (within the grace period), suspended, canceled, and expired. For each one, spell out which features the customer can use and whether they can upgrade or downgrade.

Upgrades, downgrades, and proration

A customer changing plans partway through a period is where subscription systems most often miscalculate. Here is a scenario to illustrate: imagine a customer on a monthly basic plan who upgrades to the advanced plan halfway through the billing period.

Common approaches to upgrades:

• Effective immediately, prorated difference charged now: for the remaining half month the customer is on the advanced plan. The system calculates “the advanced plan fee for the remaining days” minus “the basic plan fee for the remaining days” and charges the difference right away; from the next period, the full advanced plan fee applies.
• Effective immediately, difference added to the next bill: features upgrade at once, and the difference is collected with the next bill.
• Effective next period: the simplest, but a poorer experience for a customer who wants the new features now.

Common approaches to downgrades:

• Effective next period: the most common. The customer keeps the advanced plan they already paid for until the end of the period, and the basic plan is billed from the next period. This avoids refunds and features suddenly disappearing.
• Effective immediately, converted to credit: the difference for the remaining days is not refunded in cash but becomes a credit against the next bill.

For proration, set the rules first:

• Is it calculated by the day or by the second? If by the day, which day does an upgrade made today count toward?
• How is the proportion calculated when months have different numbers of days?
• How are fractional amounts rounded?
• If a customer changes plans several times within one period, is each change calculated separately?

These rules have no standard answers, but they must be decided before development, written into the specification, and made understandable to customers on the bill itself. A bill that just says “adjustment” without explanation is almost guaranteed to generate support questions.

Per-unit plans (for example, billed by number of accounts) follow the same logic: adding seats mid-period is charged on a prorated basis, while removing seats usually takes effect next period.

Cancellations, refunds, and e-invoices

Key points in designing cancellation:

• Separate cancel-at-period-end from cancel-immediately: most subscription cancellations mean “use up this period and don’t renew,” and the customer keeps access until the end; immediate cancellation raises the question of a refund.
• Make cancellation easy: customers can cancel themselves from their account page without contacting support. You can ask for a reason at cancellation, but don’t put deliberate obstacles in the way.
• Keep data for a while: explain in advance how long data is kept after cancellation and whether the customer can still export it after expiry.
• Resubscribing: when someone cancels and comes back, decide whether it continues the original subscription or starts a new one, and make sure the history links together.

Refunds: refund policy is a business and legal question; the system only executes it. Note that refunds must go back through the original payment channel, partial refunds must be supported, and refund records must map to the original charge and invoice. Consumer protection rules may impose different requirements depending on the type of product or service, so consult a professional for your specific case.

E-invoices: an invoice must be issued for every successful charge, usually right after payment succeeds. Situations to handle include:

• Whether the customer is an individual or a company (with a business tax ID), and whether the invoice goes to a carrier (Taiwan’s digital storage for e-invoices) or is donated.
• Whether a prorated difference gets its own invoice or is combined with the next period.
• Whether a refund requires voiding the invoice or issuing an allowance, depending on when the invoice was issued.
• From which period a change to the customer’s invoice details takes effect when made mid-period.

The mapping between invoices and subscription bills must be clear, otherwise month-end financial reconciliation becomes very painful. For integration methods, see Integrating the Taiwan E-Invoice System.

Rules decision table before development

The table below lists the rules a subscription system must settle before development. Print it out, go through it item by item with your team, and fill in your decision on each row:

Decision	Options	Your decision
Billing date	One fixed day / subscription start anniversary
Billing cycle	Monthly / yearly / both
Trial end	Convert to paid automatically / require a saved card / expire automatically
Charging method	Provider charges automatically / your system schedules payment requests
Failed-charge retries	How many retries, how far apart
Grace period	Can the customer use the service during it, and how long
After grace period	Suspend / downgrade to free / cancel
Upgrade timing	Immediate with prorated charge / immediate, added to next bill / next period
Downgrade timing	Next period / immediate, converted to credit
Proration unit	By day / by a finer time unit, and how fractions are rounded
Cancellation	At period end / immediate, and whether refunds apply
Data retention	How long after cancellation, and whether export is possible
Invoice for prorated difference	Issued separately / combined with next period
Plan price changes	Existing customers keep original terms / adjust after a transition period

Once this table is filled in, much of the system specification is done. For turning it into a formal document, see How to Write Software Requirements.

Back office and reporting: what operations needs to see

A subscription back office is more than an order lookup. What the operations team needs is:

• A complete timeline for each customer: when they subscribed, upgraded or downgraded, which charges succeeded or failed, which notices were sent, and when they canceled, so support can answer a customer’s question at a glance.
• A to-do list: subscriptions that are past due, trials about to end, and customers whose cards are about to expire.
• Manual adjustment tools: granting credits, extending a period, or manually retrying a charge, with every manual action recording who did it and why.
• Operating metrics: new subscriptions, cancellations, upgrades and downgrades, and how many failed charges were recovered, used to review plans and processes.

These functions are closely tied to member data. If you already have a membership system, subscriptions should hang off existing members rather than a separate customer list; for planning, see Building a Membership and CRM System.

The hard part of a subscription billing system is not whether you can write the code but whether the rules have been fully thought through. Every rule not decided before development turns into customer complaints, reconciliation differences, or manual fixes after launch.

Every business combines plan structure, payment provider features, and invoicing flow differently. If you are planning to move your product to a subscription model, or your existing recurring-charge process keeps running into trouble, talk to NETVANA about your subscription billing rules. All of our software work is quoted after a consultation: we first work through the decision table above with you, then plan how payments, bills, and invoices connect. What our services cover is listed in the software services overview.

Further reading: For recurring card charges and choosing a payment provider, start with Payment Gateway Integration in Taiwan. For issuing invoices and allowances after each charge, read Integrating the Taiwan E-Invoice System. To attach subscriptions to member data, see Building a Membership and CRM System. When the subscription is part of a SaaS product, read Buy SaaS or Build Custom Software. And to validate a subscription model at the smallest possible scope first, see A Guide to MVP Development.