The promise of hosting automation is simple: a client pays, and their account exists a few seconds later, without a person in between. The hard part is everything that can go wrong in those seconds: the control panel is slow, the username is taken, the package does not exist on that server, the API token expired last week.
The five steps
- The client picks a product and checks out; the order is created with its line items.
- An invoice is generated and the payment link is sent.
- Stripe or PayPal confirms payment through a signed webhook, and the invoice is marked paid.
- A provisioning job is pushed to the critical queue with the product's server, package and domain.
- The driver creates the account on cPanel/WHM or Plesk, the service becomes active, and the client is emailed their details.
Why a queue, not a direct call
A control panel call can take ten seconds or time out. If the checkout request waited for it, your clients would see spinners and your webhook endpoint would hit the gateway's timeout. A queue takes the job at once, acknowledges the webhook, and lets a worker do the slow part. When the panel fails, the job retries with exponential backoff, and after the last attempt it lands in a failed state you can see and re-run.
Suspension and termination follow the same path
Overdue invoices trigger suspension jobs on the schedule you set (dunning), payment of an overdue invoice triggers unsuspension, and a cancellation request or a long-overdue invoice triggers termination. Each is a job with a log line, so a client who says "you suspended me for no reason" is a search, not a guess.
What to watch
- The queue depth: a growing backlog means a worker died or a server is slow.
- Failed jobs by server: one server failing while others work usually means a token or package name.
- Provisioning time: a sudden jump often precedes a panel outage.
- Webhook signature failures: a few are bots; many means a rotated secret.
Hostinvo runs this flow with native cPanel/WHM and Plesk drivers, a four-tier Redis queue, retries with backoff, and a provisioning log per service. Every lifecycle action a client's service can take is also a button in the admin, so the manual path is always there when you want it.