How Provisioning Modules Map Billing Events to cPanel, Plesk, and Virtualmin API Calls

Learn how provisioning modules translate billing events into cPanel, Plesk, and Virtualmin API calls, and how to handle failures and reconcile accounts created in the panel but not in billing.

billing softwarehosting automationreseller hostingengineeringprovisioning

You've just set up a hosting billing system and connected it to your control panel. A client signs up, pays, and you expect their hosting account to appear automatically. But what if it doesn't? Or worse, what if it does, but your billing system never records it? That's where provisioning modules come in. This article explains how they work, step by step, and how to fix things when they go wrong.

What is a provisioning module and how does it work?

A provisioning module is the bridge between your billing system and your hosting control panel. It listens for billing events—like an order being paid or a subscription expiring—and translates them into API calls that create, suspend, or terminate accounts in cPanel, Plesk, or Virtualmin.

When a customer places an order, your billing system processes the payment. Once payment is confirmed, the billing system triggers a provisioning event. The module then uses the control panel's API to perform the necessary action. For example, it might call cPanel's createacct API function to set up a new hosting account.

How are billing events mapped to control panel API calls?

Each control panel has its own API, but the concept is similar across all of them. The provisioning module abstracts these differences, so you can switch panels without rewriting your billing logic. Here's a typical mapping:

  • Order Paid → Create account in control panel
  • Subscription Suspended (e.g., due to non-payment) → Suspend account
  • Subscription Terminated → Terminate account
  • Upgrade/Downgrade → Change package or resource limits

For cPanel, the module might use the WHM API 1 to create accounts. Plesk uses its XML API or REST API. Virtualmin uses its remote API via HTTP. The module handles authentication, request formatting, and response parsing.

Example: Creating an account in cPanel via API

When a new order is paid, the module sends a request to WHM with parameters like username, domain, password, and package name. WHM creates the account and returns a success or failure message. The module then updates the billing system with the account details (e.g., username, server IP) and marks the order as provisioned.

What happens when provisioning fails?

Failures can occur at any step. The API might be down, the domain might already exist, or the package might be invalid. A good provisioning module logs the error and notifies the admin. It should also retry automatically or allow manual retry. Common failure scenarios include:

  • Invalid credentials for the control panel API.
  • Insufficient resources on the server.
  • Duplicate account (domain already exists).
  • Network timeouts.

When a failure happens, the billing system should not mark the order as complete. Instead, it should flag it for review. Some systems create a pending action that can be retried later.

How to reconcile when an account is created in the panel but not in billing

This is a common and tricky problem: the control panel successfully creates the account, but the billing system never records it—perhaps because the API response was lost, or the module crashed after the API call. Now you have an orphaned account in the panel that isn't linked to any client in billing.

To fix this, you need a reconciliation process. Here's how to approach it:

  1. Detect orphaned accounts: Periodically fetch a list of all accounts from the control panel and compare with the list of active services in your billing system. Any account not in billing is orphaned.
  2. Investigate: Check logs to see if the account was created as part of a failed provisioning attempt. Look for matching domains or usernames.
  3. Link or remove: If the account belongs to a client who paid, manually create the service in billing and link it to the panel account. If it's a mistake, terminate the account in the panel.
  4. Prevent recurrence: Ensure your provisioning module uses idempotent operations. For example, before creating an account, check if it already exists. Also, implement a two-phase commit: first create the account in billing as 'pending', then call the API, then update to 'active' only on success.

Some billing systems have built-in reconciliation tools. If not, you can write a script that uses the control panel API and your billing system's API to sync.

Best practices for reliable provisioning

  • Use webhooks or callbacks: Instead of polling, have the control panel notify your billing system when an account is created. Not all panels support this, but it reduces race conditions.
  • Log everything: Keep detailed logs of API requests and responses. This helps debug failures and reconcile.
  • Implement retries with backoff: For transient errors, retry after a delay.
  • Monitor orphaned accounts: Set up alerts for accounts that exist in the panel but not in billing.

If you're using a platform like Teculiar, which automates hosting, domains, and VPS reselling, provisioning modules are built-in and handle these complexities for you. You can focus on selling while the system manages the API calls and reconciliation. For more details, see our platform page.

What to do next

  • Review your current provisioning setup and identify any gaps in failure handling.
  • Implement a reconciliation script or use built-in tools to detect orphaned accounts.
  • Test your provisioning module with simulated failures to ensure it recovers gracefully.
  • Consider a platform that handles provisioning automatically—check our pricing for options.

Take one step today: audit your last ten provisioning events to see if any accounts were created without a corresponding billing record.