Your hosting account is usually provisioned within minutes of payment. Activation is not something you do. It happens automatically, and the welcome email is the signal that it is done.
What follows is what to do with that email, in an order that gets a working site without waiting on DNS.
The welcome email
It contains four things you will need repeatedly:
cPanel URL https://yourdomain.com/cpanel (or the server hostname) Username your cPanel username Password your cPanel password Nameservers ns1... and ns2...
Save it somewhere you will find it again. If it has not arrived within an hour, check spam, automated account emails land there routinely, and then check the client area, which shows the same details.
Log into cPanel before touching DNS
You can set everything up before your domain points here, and that is the right order. The server hostname form of the cPanel address works regardless of DNS:
https://server-hostname:2083
Log in and change the password to something you generated yourself, stored in a password manager. This login opens every file, database and mailbox on the account.
Then set the contact address under cPanel's preferences to a mailbox you actually read, and preferably not one on this account, quota warnings and important notices go there, and if the account has a problem you still want the warning to arrive.
Build the site before switching DNS
If this is a new site, install what you need now. The one-click installer handles WordPress in about two minutes. Installing WordPress with one click sets out the form.
If you are moving an existing site, restore it here while the domain still points at the old host. Ahosting offers free migration, so opening a ticket is usually better than doing it yourself. Requesting a free migration walks through what to provide.
Either way, nobody sees this work. The domain still resolves to wherever it currently lives.
Test with a hosts file entry
Add a line to your computer's hosts file mapping the domain to the server's IP address. Your machine then loads the new server while everyone else continues to reach the old one.
Browse the site properly, homepage, a deep page, a form, the admin area, checkout if there is one. A failed test at this point costs nothing, because the live site is untouched.
Remove the entry when you are done, or you will keep seeing the new server after the switch and be unable to tell whether it worked.
Point the domain here
Once the test passes, change the nameservers at your registrar to the two in your welcome email. This is the irreversible step, and it is the one to do last.
Propagation takes up to 24 to 48 hours. During that window some visitors reach the old server and some the new one, which is expected and cannot be forced. There is more on what to record beforehand so nothing is lost in changing nameservers.
If you are moving from another host, keep the old account alive for at least a week. Orders and mail arriving during propagation may land there.
After the domain resolves here
Check SSL. Certificates cannot be issued before the domain points here, because the authority verifies control by reaching it. Once it resolves, check the SSL status page in cPanel and run AutoSSL for anything not covered.
Check email. If mail is handled on this account, send a message from outside and confirm it arrives. Mail failing is silent, unlike a website failing.
Set up backups. Whatever the old host was doing does not follow you. Creating and restoring backups in cPanel deals with taking one before the first risky change.
If nothing was provisioned
An order held for a routine fraud check is the usual reason, particularly on a first purchase. You will normally have received a verification email (check spam) and replying to it releases the order.
If it has been several hours with no email, open a ticket with the order number. Contacting support deals with what to include so it is resolved in one exchange.
If you have not ordered yet, How to Purchase a Hosting Plan Step by Step covers the steps and the choices along the way.
Confirm what was actually provisioned
The welcome message describes what was ordered. What exists on the server is a separate question and worth confirming before building anything.
curl -sI https://yourdomain.example/ | head -1 dig yourdomain.example A +short curl -sI http://server-ip/~username/ | head -1
Read three things inside the panel on the first visit: the primary domain, the disk and file allowances, and the PHP version. Each shapes what you can install, and each is easier to have corrected on day one than after a site exists.
Where the plan includes a fixed number of accounts, databases or mailboxes, note those figures too. Reaching one of them halfway through a build is avoidable, and it is the sort of thing nobody checks until the creation fails.
Set up access properly before it is urgent
The first day is when account access is easiest to arrange and the least interesting to think about.
Three things to do while nothing depends on them. Enable two factor authentication. Set the contact address to something that does not live on the account being protected. And create a separate login for anyone else who will work on the site rather than sharing the main one.
curl -sI https://yourdomain.example:2083/ | head -1
The last matters most for a site somebody else builds. A developer with their own account can be removed when the work ends, and a shared password cannot be, which is why so many sites are still accessible to people who left years ago. Securing your hosting account covers the rest.
Know what the plan does not include
Most early support requests are about something that was never part of the service, and knowing the boundary saves the round trip.
The hosting covers the server, the software it runs and the account. It does not cover the content of the site, the code somebody wrote for it, or a third party service the site connects to.
The useful distinction when something goes wrong is whether the problem exists for every site on the server or only for yours. The first is the host's, the second is the site's, and establishing which takes a minute.
Backups deserve a specific question rather than an assumption, since what is kept and for how long varies and is the one thing you cannot arrange retrospectively. What to ask before moving to a new host covers the questions worth asking early.