"Set up automatically" is one of those phrases that every hosting company uses and almost none of them explains. It is worth explaining, because knowing what the machinery is doing turns the ten minutes after a payment from an anxious wait into a wait.
The sequence
When a payment clears, five things happen in order, and each one is visible somewhere in your client area:
- The payment provider confirms the charge and the invoice is marked paid. Nothing before this point matters; we do not act on a payment that has been started but not confirmed.
- The order is accepted. Its row under Orders moves from pending to active.
- A provisioning job is queued for each service the invoice paid for. This is the step people assume does not exist: the panel does not talk to the hosting platform while you are still on the payment page, because a slow or unreachable platform would then look like a failed payment.
- A worker picks the job up and the matching module makes the actual request: an account on the hosting server, a virtual machine on the virtualisation platform, a container on the game panel.
- The platform answers, the service flips to Active, its username and password are stored against it, and a welcome e-mail goes to the address on your account.
For most plans this is minutes rather than hours. The gap you notice is almost always step four: building a virtual machine means copying a disk image, and a container has to install its runtime before it will start.
Why the queue matters
Doing the work on a queue rather than inside the web request buys three things that are hard to get any other way.
A failure is not final. If the platform is busy, rate-limiting us, or restarting, the job does not fail: it is retried, with the gap between attempts doubling each time, from about a minute up to a ceiling of a few hours. Most problems of this kind resolve themselves two attempts later with nobody having been told. A problem that is genuinely permanent, such as a plan name that does not exist on the server, stops retrying and raises an alert for our side instead of looping forever.
A duplicate does nothing. Payment notifications arrive twice more often than you would expect: a webhook is re-sent, a customer refreshes the return page, two parts of the system both notice the same payment. Every provisioning action carries a key built from the service and the cause, and a second job with the same key is discarded. This is why paying an invoice twice over cannot produce two hosting accounts.
Nothing changes locally until the remote side says yes. A module never writes to our database. It returns a result, and the panel applies it. If the account was not created, your service does not claim to be active.
What you see while it runs
The service appears under Services as soon as the order is accepted, with the status Pending. Pending means the row exists and the platform has not finished building it. When it becomes Active, the login details are on the page from that moment. You do not have to wait for the welcome e-mail, which is a copy rather than the original. Finding your login details shows where they sit.
The orders that are not automatic
Two cases break the pattern, and both are deliberate.
The first is fraud screening. Every order is screened before it is accepted. The screening never refuses anybody on its own; what it can do is hold the order so a person reads it, which typically happens when the billing details and the card do not look like they belong together, or when several accounts appear from one place in a few minutes. A held order sits as pending and we come back to you, usually asking you to confirm something rather than to send documents.
The second is the plans that are built by a person on purpose. A dedicated server is physical hardware: it has to be prepared, installed and handed over, and no queue makes that instant. Some other plans are configured by our team too, because an order with something unusual in it is better read by somebody than handed to a script. The plan page says which, and the order confirmation says what to expect.
If it stays pending
Give it an hour. Provisioning that is retrying looks identical from the outside to provisioning that has stopped, and most of the time it is the former. After that, open a ticket with the service number: it is the quickest route, because the ticket lands beside the job's own history and whoever picks it up can see which step did not answer. Do not re-order; the second order will be charged and the first one is the one that needs unsticking.