WHMCS vs FOSSBilling: which billing platform should a hosting business run?

This is the system that sends your invoices, provisions your services and holds your customer list. Getting it wrong is expensive to undo, so it is worth spending an afternoon on before you commit.

Provibr does not sell you either one. What we have is two integrations written into these panels: a WHMCS provisioning module that is built and shipping, and a FOSSBilling coupling we researched by reading the running 0.8.5 source. So the parts of this page about the money and the ecosystem come from each vendor's own pages; the parts about how the code actually behaves come from having been inside both.

The money, because that is where this usually starts

WHMCS is proprietary and sold as a monthly subscription. FOSSBilling is free and open source. That single line decides the comparison for a lot of people, but the honest version has more to it than "free wins".

WHMCS is sold as a monthly subscription. The self-hosted tiers, checked on 21 August 2026, are Plus at $34.95/month (up to 250 active clients), Professional at $54.95/month (500 clients) and Business at $84.95/month (1,000 clients); a fully managed cloud option starts at $9.99/month for 25 clients. The licence is priced by your number of active clients, so the cost grows as you do.

FOSSBilling describes itself as "free and open source hosting automation" with "no hidden costs, no vendor lock-in". There is no licence fee and no client-count tier.

There is one piece of context that changes how you read the WHMCS number. WHMCS is owned by WebPros, the same company that owns cPanel and Plesk, and its price has moved up more than once in recent years.

WHMCS, cPanel and Plesk are all owned by WebPros. If you run cPanel or Plesk alongside WHMCS, all three of your recurring software costs sit with the same vendor.

FOSSBilling's counterweight is not price, it is maturity. It ships as 0.8.5, a pre-1.0 version number, and its own maintainers treat it as such. WHMCS has been the market default for well over a decade, and it shows in the number of payment gateways, domain registrars and provisioning modules that target it out of the box. FOSSBilling's extension catalogue is a fraction of the size.

What "you can read the code" actually buys you

This is the difference that does not show up until something breaks at 2am.

WHMCS's core is ionCube-encoded. You cannot read it, you cannot patch it, and when a function misbehaves your only recourse is a support ticket. FOSSBilling is plain PHP on GitHub: when the running 0.8.5 image does something surprising, you open the file and look. We did exactly that to answer a question the documentation would not: how FOSSBilling discovers a provisioning driver. The answer was a runtime directory scan, which we would never have been sure of from docs alone.

That cuts both ways. An encoded, single-vendor core is also a supported core: someone is paid to keep it working, and a WHMCS upgrade is a known quantity. An open core is yours to fix and yours to break.

Under the hood, measured from the module side

Everything in this section is something we established while building the Provibr module for WHMCS and reading the FOSSBilling source. It is the part no marketing page will give you.

Three of those rows are worth a sentence.

The bundled template engine is a real upgrade hazard on the WHMCS side. WHMCS ships its own copy of Smarty, and that copy has moved from Smarty 3 to Smarty 4 across recent WHMCS releases, a breaking jump. A custom module carrying template code has to survive whichever version the WHMCS you land on decided to bundle, regardless of what you tested against. FOSSBilling uses Twig, and because the core is not encoded you can see exactly which version you are on.

FOSSBilling has two ways to connect a service, and the distinction shapes everything. A server manager is a single PHP class shaped for shared hosting. The six built-in ones are cPanel, DirectAdmin, Plesk, Hestia, CWP and a Custom driver. It drops into a fixed core directory and the panel finds it by scanning the folder; there is no registration list to edit. A service module registers its own product type with its own admin and customer UI, which is what you need for anything that is not username-and-domain shared hosting. WHMCS has one provisioning shape; FOSSBilling makes you choose.

WHMCS owns the truth about a service's state. A provisioning function returns the string "success" and WHMCS records the account as active; the module is telling WHMCS what happened, not asking. That is clean, but it means a module cannot quietly correct WHMCS's idea of reality; the reconciliation has to be deliberate.

So which one should you run?

Run WHMCS if you want the largest ecosystem, you already rely on modules that only target it, or a paid, supported, predictable upgrade path is worth a monthly bill to you. Reseller-heavy and larger operations lean this way, and the client-count pricing is easier to swallow when each client is paying you.

Run FOSSBilling if cost matters, you value being able to read and patch your own billing core, and your needs are inside what a still-maturing 0.8.x platform covers. Small and technical operations fit it well. Accept in exchange that "0.8" is the project's own version number and not a competitor's dig, and that the extension catalogue is smaller.

Stay on WHMCS for now if you run it today and it is not your biggest line item. Migrating a live customer base, its invoices and its provisioning links is not a weekend job.

Try FOSSBilling first if you are starting fresh, or you can stand up a parallel instance and move cohorts across without a hard cutover.

The part both of them leave to you: what you actually sell

A billing panel is a cash register and a customer list. It does not, on its own, run a virtual machine, a hosting account or a game server. It calls out to something that does. That something is where the two panels look identical, because both of them can talk to the same Provibr account over one REST API.

We know that API from the module side, and it has edges worth naming. A repeated order after a dropped connection returns the server id in a different place than a fresh one, so a module that reads only the top-level field loses track of the machine it just created. The idempotency key has to carry an installation fingerprint, because the uniqueness check is global rather than per-reseller. And anything that touches infrastructure comes back as a 202 with a Location header rather than a finished result, so the module has to follow the command rather than assume it is done. Those are the kinds of thing you find by building, not by reading a spec, and they are the same on whichever billing panel sits in front.

Which means the billing decision and the provisioning decision are separable. You can pick WHMCS or FOSSBilling on the merits above, and sell VPS, hosting and game capacity through either, because the layer underneath does not care which cash register you chose.

Read next

• Provibr vs WHMCS: where a billing panel ends and an infrastructure layer begins
• WHMCS alternatives: the wider billing field
• The public API: the REST surface a reseller module talks to
• Billing in Provibr: proformas, invoices and how capacity is metered

WHMCS and FOSSBilling prices, ownership and self-descriptions were read from the vendors' own pages on 21 August 2026. Everything about how the two panels' provisioning code behaves was established while building the Provibr WHMCS module and reading the running FOSSBilling 0.8.5 source.