Billing modules

Under Server, Downloads holds a module for each of WHMCS, FOSSBilling and Blesta. They are separate modules, because the three billing systems are shaped nothing alike, and each unpacks self-contained. They are fetched with your own signed-in session rather than from a public address, so a link copied out of the browser is worth nothing to anybody else.

Each release of Dashmox carries them, which means a server with no route to the internet still has them, and the version it has is the one built against the panel it is running.

• Create. A paid order makes the customer on the panel and the website under them.
• Suspend and restore. Flips the whole customer, which signs out their people and reconfigures their websites.
• Terminate. Removes every website first, then the customer, in that order because the panel refuses a customer who still owns one.
• Change package. Moves a customer onto another plan you already sell.
• Usage. Reports peak disk over the billing period, from the daily samples.

What a customer sees is a read-only summary on their service page: status, disk, transfer over thirty days and certificate expiry, with an optional link to the panel. Every change is still made in the panel, so it is built once rather than twice and kept in step for ever.

Make an integration key in the panel under Server, then Integrations, granting it the permissions the module needs. It belongs to the installation rather than to a person, so it does not vanish when whoever made it leaves.

Add the server in your billing system with the panel's hostname, its port, and the key. In WHMCS it goes in the access hash; Blesta has a field for it and stores it encrypted. Then press Test connection: it checks the key is a Dashmox one before opening a socket, that it may read hosting packages, and that the panel has packages at all. A missing permission is found there rather than by the first customer to order.

Several Dashmox servers work with no extra configuration: the module reaches whichever panel a service is assigned to. Where new accounts go is a server group in your billing system, and its fill type does what a host would ask for: the server with the fewest accounts, a random one, or filling each in turn.

One thing is worth knowing before trusting a balanced group. The count behind "least accounts" is your billing system's own, so a panel that also holds websites it never created looks emptier than it is, and the balancer sends more work to the fullest machine. A tool that ships with the module finds exactly that, in both directions.

Push packages copies the products you sell onto a panel. One direction only, and it only ever adds: an allowance somebody is already hosting under is not something a sync script should move. It says what it would do unless you tell it to go ahead.

Find orphans is read-only and compares both directions. Websites on the panel your billing system does not know about are the ones that break a balanced group and that nobody is invoicing. Services being billed whose website is gone are somebody paying for nothing.

There is no single sign-on. The link to the panel is a plain link to its sign-in page and your customer enters their own panel password. A one-time token that logs somebody in is worth exactly as much as a password, and what it buys is one fewer sign-in on a page most people visit rarely.

There is no reseller role, deliberately, so nothing here sells hosting under your customers' own branding. A module operation with nothing behind it refuses by name rather than reporting success, because a method that quietly does nothing tells a host their customer's password changed when it did not.