Billing
Invoice-and-pay versus automatic charging
Two ways to collect money for hosting, with different cash flow, different disputes and different failure modes. Which one you have is often an accident.
9 min read · Reviewed 2026-09-21
In short
Before your first customer, settle six things: what you are actually selling, whose hardware it runs on, how money is collected, who answers a ticket at 2am, what happens when a provisioning request fails halfway, and what your records say when a customer disputes a charge. Every one of them is cheaper to decide now than to retrofit.
Servers falling over is the failure people plan for. The one that is harder to recover from is not being able to answer, six months in, questions like which of these accounts is actually paid for, why does this customer have two subscriptions, or did that renewal go through. Those are records problems, and they are decided by choices made in the first month.
Decide what you are selling before you price it
A hosting product is a bundle of promises: disc space, a control panel, a mail service, backups, a support response time. Each promise has a cost and a failure mode. Write the bundle down as a product with a term — monthly, annual — and a price, and resist selling anything that is not in that list. Bespoke deals are the single biggest source of billing confusion in small hosts, because they exist in an email rather than in the catalogue.
- What resources are included, in the units your panel enforces. If your panel measures disc in gigabytes and you sold "unlimited", you have a promise nothing can hold you to and nothing can stop you breaking.
- What the term is, and whether it renews. A monthly product that renews and an annual product that does not are two different businesses.
- What support is included — hours, channels and what counts as in scope. "Email support" without hours is a promise of 24/7 that you will break.
- What happens at the end. Data retention after cancellation is a decision you must make before somebody cancels, not during the argument.
Decide whose hardware it is
There are three common shapes and they have different operational weight.
| Arrangement | You are responsible for | The failure that will find you |
|---|---|---|
| Reseller account | Customers, billing, first-line support | Your upstream suspends the parent account and every customer goes down at once |
| Your own VPS or dedicated servers | All of the above, plus the operating system, the panel, backups and security | A kernel update at the wrong moment, with no second machine |
| Managed platform | Customers and billing | Less control over the timing of maintenance you have to explain to customers |
Whichever you pick, the operational rule is the same: know which machine each customer is on, by name, and be able to answer it without logging into anything. A billing system that records the server alongside the account is doing real work; one that records only a plan name is not.
Decide how money is collected
There are two models and the difference matters more than people expect. Either you raise an invoice and the customer pays it, or you hold a payment instrument and charge it automatically. The second collects more reliably and creates a category of dispute the first does not have. We wrote this up separately in invoice-and-pay versus automatic charging, because it is an easy decision to make by accident.
Whichever you choose, do not let provisioning depend on a payment you have not verified. "Marked as paid" and "the money arrived" are different facts, and a system that treats them as one will provision for free at some point.
Decide who answers, and when
One person answering everything works while every open conversation fits in their head, and stops working some time after that. The transition is painful because it is not a hiring problem, it is an ownership problem: two people looking at the same queue will both assume the other has it. Give every conversation exactly one owner and make the owner visible. That is the whole of it, and it is covered in hosting support with Kanban and clear ownership.
Decide what happens when provisioning fails halfway
This is the one that is easy not to plan for, and it is the one that costs real money. A request goes to a control panel, the connection drops, and you do not know whether the account was created. Retrying might create a second one. Not retrying might leave a paying customer with nothing.
The answer is not cleverness, it is bookkeeping: record that you asked before you ask, hold the account name so nothing else can take it, and when the outcome is unknown, stop and make a person look. Retrying a request that may have had an effect is how one hosting account becomes two. There is a fuller treatment in safe hosting provisioning and duplicate prevention.
Decide what your records will say in a dispute
A year from now somebody will say they cancelled and you will need to know whether they did. Design for that day: every act that changes what a customer owes or has should leave a line saying who did it, when, and why. This costs nothing to build in at the start and is close to impossible to reconstruct later.
A first-month checklist
- Write down three to five products with real resource limits and terms. No bespoke deals yet.
- Choose the panel and know how to create, suspend and reinstate an account by hand before you automate it.
- Decide invoice-and-pay or automatic charging, and write down what happens when a payment fails.
- Set a support promise you can keep on your worst week, not your best.
- Test a restore, not a backup. A backup you have never restored is a hope.
- Write the cancellation and data-retention rule down, before anybody cancels.
- Decide who is allowed to issue a refund, and make that one person.
Questions
How many customers before this matters?
The records decisions matter from the first customer, because they are the ones that cannot be retrofitted. The staffing and process decisions can wait until you are answering more tickets than you can hold in your head. There is no general number for that; the sign is a reply you had to search for, or a customer who had to repeat themselves.
Should I build my own billing system?
Almost never. The interesting part of a hosting business is the service you give customers; the billing is a solved problem with a large number of edge cases you will rediscover one at a time. Buy or adopt something, and spend the saved time on support.
What early mistake is hardest to undo?
Selling a bespoke arrangement to an early customer because they asked. It feels like good service, and it becomes a record nobody can reconcile when that customer later disputes an invoice.
Sources
Official documentation, each requested on 21 September 2026. Provider behaviour changes; check the source before relying on a detail.