The gap between "this invoice is overdue" and "this server is gone" is a policy, not a feature. Most businesses never write it down, so it exists anyway as whatever the software defaults to.
Mario Marin6 min readThe gap between "this invoice is overdue" and "this server is gone" is a policy, not a feature. Most hosting businesses never write it down, which means it exists anyway — as whatever the software defaults to, plus whatever the person on duty decides.
Here is how to design that timeline so it protects your revenue, survives a legal challenge, and does not destroy data belonging to a customer who was about to pay.
Not legal advice. Notice periods, data-retention obligations and consumer-protection rules vary by jurisdiction and by whether your customer is a business or a consumer. Have your terms reviewed locally. This post covers the operational design.
A service that stops being paid for passes through five states, and conflating any two of them causes problems.
The single most valuable design decision is making states 3 and 4 far apart. Suspension costs you nothing but the disk the data sits on; termination is irreversible and is where the angry emails come from.
The specific numbers depend on your market and your margins. The shape matters more than the values.
| Day | Event | State |
|---|---|---|
| -7 | Renewal notice: amount, date, how to cancel | Active |
| 0 | Invoice due; auto-payment attempted | Active |
| 1-7 | Payment retries and reminders | Overdue |
| 7 | Final notice, naming the suspension date | Overdue |
| 10 | Suspend — service stopped, data intact | Suspended |
| 10-30 | Recovery window; unsuspend on payment | Suspended |
| 30 | Termination notice sent | Suspended |
| 37 | Terminate — resources released | Terminated |
| 67 | Backups purged | Purged |
Every state change is preceded by a notice naming the next state and its date. That is what makes the timeline defensible: nobody can say they were not told, and the notice itself recovers a meaningful share of the payments.
If your billing runs as a daily batch, the order of operations inside that run decides whether you suspend customers who were about to pay automatically.
The correct order is: generate renewals and any pending changes first, then attempt automatic payment, then run suspension and termination checks. Run suspension before auto-payment and you will suspend a customer whose card would have been charged successfully ninety seconds later. They will notice, they will open a ticket, and they will be right.
This is a one-line ordering decision with a large customer-experience consequence, and it is worth confirming explicitly with any platform you evaluate.
A service marked suspended in a database while the VPS keeps running is not suspended — you are still paying for the capacity and the customer has noticed nothing. Suspension has to reach the control plane: the account disabled on the panel, the container or VM stopped on the hypervisor, the port shut or the machine powered off on bare metal.
Equally important is that unsuspend has to work. It is tested far less often than suspend, and a customer who has just paid to restore their service is the worst possible audience for a broken code path.
Suspend the service. Do not suspend the customer's ability to log in and pay you. Locking someone out of the portal that holds the payment button is self-defeating, and it happens more than you would expect — usually because "suspend the account" was implemented as one flag covering both.
Leave the ticket system reachable too. A suspended customer with a genuine billing dispute needs a route to you that is not their bank, because their bank is the alternative and it is a far more expensive one for you.
Data export. Decide whether a suspended or terminated customer can retrieve their data and for how long. In some jurisdictions, for some data, you may be obliged to provide it.
Resource release. Termination has to return the IP addresses to the pool, free the rack unit, and mark the hardware available. If it does not, you will run out of address space with plenty of addresses sitting on dead services, and rack capacity you cannot find.
Domains are different. A domain is the customer's asset with a registry expiry date that has nothing to do with your invoice. Do not terminate a domain the way you terminate a VPS; follow the registrar's redemption path.
Final invoice and credit. Terminating mid-cycle raises the question of the unused period. Answer it in the terms.
FluxBilling runs the daily lifecycle in the order described above by design: scheduled downgrades and pending changes are applied first, then renewals and cancellations are processed, then automatic payment runs against the invoices that produced, and only then do suspension and termination checks run — specifically so that services get a chance to be paid before being suspended. Invoice reminders and service renewal reminders run in the same pass.
Suspension and termination are separate lifecycle states rather than one flag, so a service can be stopped without being destroyed, and termination returns IP allocations to the pool and hardware to inventory through the same records that allocated them. Provisioning plugins expose suspend and unsuspend as first-class operations — the eNom domain integration, for example, carries suspend, unsuspend, registrar lock and unlock as distinct flows rather than treating termination as the only lever.
See provisioning, IPAM and current pricing.
Write the timeline down, publish the parts customers need, and put every date in a notice before it happens. Then test the recovery path, not just the enforcement path — pay a suspended invoice and confirm the service comes back without a human. Enforcement gets built because it protects revenue; recovery is what actually collects it.
A chargeback is the customer’s bank deciding for you, taking the money, and charging a fee whether you win or not. Most are communication failures, and three small fixes remove them.
Getting money in is built carefully. Getting it back out is built in a hurry, and that is where the accounting goes wrong. Four operations that look like one.
A gap in an invoice sequence is a question you have to answer, and "the software did it" is not an answer. Where hosting businesses generate gaps and how to stop.