Why Salieno Core's Billing Module Doesn't Try to Be WHMCS

The Billing Trap#

Every hosting control panel wants to own your billing. cPanel tried with cPanel Billing. Plesk has its own extensions. InterWorx, DirectAdmin, Virtualmin — they all have hooks, plugins, or built-in modules that promise to manage your invoices, subscriptions, and client accounts.

And every time, the same problem emerges: the billing module becomes the weakest link in the stack.

When we set out to build Salieno Core's billing component, we made a deliberate architectural choice that surprises a lot of hosts who evaluate the platform. We built billing to be intentionally limited, boringly reliable, and trivially replaceable.

That's not a bug. That's the entire point.

What Our Billing Module Actually Does#

Let's be specific about what's included and what isn't.

Salieno Core's billing module handles the core loop that a hosting reseller actually needs day-to-day:

• Account provisioning and suspension — creating, suspending, and terminating hosting accounts based on payment status
• Invoice generation — recurring invoices for shared hosting, reseller plans, and add-on domains
• Payment gateway integration — Stripe, PayPal, and Mollie out of the box, with a clean interface for adding others
• Client self-service portal — customers can view invoices, update payment methods, and manage basic account settings
• Domain registration hooks — integration points for registrars like OpenSRS, ResellerClub, and the WHMCS domain registrar API

That's the core. It covers the 80% case: a hosting reseller with 50 to 500 accounts who needs to bill monthly, handle renewals, and provision automatically.

What It Doesn't Do (And Why)#

Here's where we diverge from the WHMCS model. Our billing module does not include:

• A full ticketing system
• Affiliate program management
• Complex promotional coupon engines
• Multi-currency conversion with real-time exchange rates
• Built-in fraud scoring beyond basic gateway checks
• Server monitoring and alerting
• Domain marketplace or reseller storefront templates

The instinct from product teams is to build all of this. More features means more value, right? But in practice, every feature you bolt onto a billing system becomes a surface area for bugs, security issues, and maintenance debt.

WHMCS has over 1.5 million lines of code. It has had critical RCE vulnerabilities (CVE-2023-46808 and CVE-2023-46809 in late 2023, for example). The more a billing platform tries to be, the more it becomes a liability.

We chose to keep ours under 40,000 lines. That's a feature.

The Replaceability Principle#

Here's the architectural decision that matters most: Salieno Core's billing module communicates with the provisioning layer through a documented REST API. The billing module is just one possible client of that API.

What this means in practice:

• You can swap our billing module for WHMCS, Blesta, or Clientexec by writing an adapter against our provisioning API
• You can run billing entirely separately on a different server or container
• You can replace our Stripe integration with a local payment gateway without touching provisioning logic
• You can run Salieno Core with no billing module at all, provisioning accounts manually or through your own tooling

This is the opposite of how cPanel and WHMCS work together. In that ecosystem, WHMCS is deeply coupled to cPanel's API through specific module files, and cPanel's pricing is tied to account counts that WHMCS reports. They're entangled.

We wanted billing to be a pluggable component, not a load-bearing wall.

Why This Matters for Reseller Economics#

A hosting reseller running 200 accounts at $8/month generates roughly $19,200 in annual revenue. After infrastructure costs (say $3,000-$6,000/year for a few VPS or dedicated servers), the margin is thin.

WHMCS costs $18.95/month for up to 250 clients on their Plus plan. That's $227/year — about 1.2% of revenue. It doesn't sound like much, but it's a fixed cost that scales poorly. At 1,000 accounts, you're on the Business plan at $44.95/month, and the feature set you're paying for is mostly things you don't use.

More importantly, WHMCS becomes a single point of failure. If WHMCS goes down, you can't provision new accounts, customers can't pay invoices, and your support queue fills up with "I can't log in" tickets.

By keeping our billing module simple and self-contained, it runs on the same server as your control panel with no external dependencies. If you need to migrate it, it's a database dump and a config file. There's no license server to contact, no activation to manage, no version compatibility matrix to navigate.

The Honest Trade-offs#

This approach has real limitations, and we should be upfront about them.

If you're running a hosting business with 5,000+ accounts, complex reseller hierarchies, or you need sophisticated fraud detection and affiliate tracking, our built-in billing probably isn't enough. You'll want to use a dedicated billing platform like Blesta (which has a clean API and modular architecture) or even WHMCS if the feature set justifies the coupling.

We also don't have a visual template system for the client portal. If you want a fully branded, pixel-perfect customer experience, you'll need to build a frontend against our API. For a one-person hosting operation, that's probably overkill.

The goal was never to replace WHMCS for everyone. The goal was to make sure that for the majority of small-to-mid-size hosting resellers, you don't need to buy, maintain, and secure a separate billing platform just to get started.

The Bigger Picture#

Hosting software has a bloat problem. Every platform wants to be the one tool you run everything on. Control panel, billing, support, monitoring, security, DNS, email — all in one monolithic stack.

That sounds convenient until you need to upgrade one component. Or until one component has a vulnerability that exposes everything else. Or until the vendor raises prices and you realize you can't extract any single piece without rebuilding your entire operation.

Salieno Core's billing module is small because billing should be small. It should do the essential job — take money, provision accounts, send invoices — and then get out of the way.

If you need more, the API is documented and stable. Build on it, swap it, or ignore it entirely. Your billing system shouldn't be the thing that locks you in.