Skip to main content

Callback Hostnames · Beginner · an hour

How to take payments online — Gateways Call Back to a Hostname, and Hostnames Move

Payments are being taken and orders are not being marked paid, because the webhook is still calling a hostname you stopped answering for last month.

The short answer

Let the gateway hold the card, and keep a record of every place your domain is written into the payment chain: the webhook or callback URL, the domain verification the provider holds, the return URLs, and the descriptor customers see on their statement. All four are hostnames or names, and all four need attention the day you move.

The setup itself is ordinary. Open and verify the merchant account early, install the provider's official extension, paste the API keys, test the failures as well as the successes, then go live and buy something small and real.

An hour at beginner level, and the parts that outlast the setup are the ones that mention your domain.

By the Hosting & Domains team · Reviewed 24 August 2026

Beginner

Assumed knowledge

an hour

Budget of time

5

Steps laid out

24/7

Desk hours

Card details are tokenised on the provider's own infrastructure by Stripe, PayPal and the rest, so raw numbers never reach your hosting and you stay in the lighter PCI bands rather than the heavy ones. That is the security half, and it is largely handled for you.

The half that is yours is the set of URLs and names the gateway holds about you. Those are configured once, forgotten, and then break silently on the day the site's address changes.

Verification takes days rather than minutes at most providers, so start the merchant account long before the launch date rather than during launch week.

Let the gateway hold the card

Every mainstream provider tokenises on their own infrastructure. Card numbers do not touch your server, which keeps your compliance obligations light and means a hosting compromise is not a card breach.

That is the single most important architectural decision on this page, and it is made simply by using the official extension rather than trying to be clever.

Four places your domain is written into the payment chain

The webhook or callback URL, which the provider requests to tell your site a payment succeeded, failed or was refunded. The domain verification some providers require before a wallet button will render. The return and cancel URLs the customer is sent back to. And the statement descriptor, which is often derived from your trading name and sometimes displays a domain.

Write these four down alongside the API keys. They are the checklist for any future move, and they are the reason a domain change breaks payments in ways that look like a gateway fault.

The webhook is the one that fails silently

A failing webhook does not stop a payment. The customer pays, the money moves, and your site never hears about it — so the order sits unpaid, the stock does not decrement, and the confirmation email never sends. From the customer's side everything worked, which is why this is discovered through complaints rather than through monitoring.

After any change to the site's address, certificate or hostname, open the provider's dashboard and look at the webhook delivery log. Every provider keeps one, most will replay failed events, and reading it takes a minute.

Wallet buttons need the domain proved

Some payment methods will not render until the provider has verified that you control the domain, usually by a file served from a specific path or by a DNS record. If you move to a new name, or add a checkout on a subdomain, that verification has to be repeated for the new hostname.

The symptom is a payment option that simply does not appear, with no error anywhere. Check the provider's domain list whenever a wallet button goes missing rather than assuming the customer's device is at fault.

Test the failures, then go live carefully. Every provider publishes test card numbers for declines, for authentication prompts and for timeouts. Until the unhappy paths say something useful to the shopper, the checkout is unfinished.

Then replace sandbox keys with live ones, buy something small and real, and refund it. Confirm the money moved, the order was recorded, the webhook fired and the refund landed before you announce anything.

An order going through on a shop that never made the buyer wait for it

One place to see what your name is doing

Records, certificates and the registration sit in one account here, which is what makes a payment post-mortem short: when a webhook stops arriving, you can check the hostname's record, its certificate and the registration's renewal state without logging into three services.

Free SSL comes with every plan and reissues before the old certificate lapses. That matters more than usual on a payment path, because a provider will refuse to deliver a webhook to a hostname whose certificate has expired.

  • Free SSL on every plan, reissued before the old one lapses
  • Records and registration behind a single login
  • A 99.9% uptime target, watched around the clock
  • A desk staffed every hour of every day

Why Hosting & Domains

Standard on every plan

Card data kept off your server

Tokenisation on the provider's infrastructure keeps you in the lighter compliance bands and means a hosting compromise is not a card breach.

The four domain touch-points listed

Webhook URL, domain verification, return URLs and statement descriptor — written down once and used as the checklist for every future move.

The silent webhook failure explained

Payments succeed while orders stay unpaid. The delivery log in the provider's dashboard is where that is diagnosed, in about a minute.

Wallet buttons that vanish, solved

A missing payment option is usually an unverified hostname rather than a customer's device, and the provider's domain list says so plainly.

Failures tested on purpose

Declines, authentication prompts and timeouts each get a test, because the unhappy paths are what the shopper actually experiences.

A real first transaction

Live keys, one small genuine purchase, then a refund — with money, order, webhook and refund all confirmed before you announce anything.

Quick Start

Order placed to site online

  1. 1

    Open and verify the merchant account early

    Business details, bank account, identity documents. Verification takes days rather than minutes, so start it long before launch week rather than during it.

  2. 2

    Install the official extension and paste the keys

    Each provider ships one. Take the API keys from their dashboard, choose which card brands to show, and leave sandbox keys in place until testing is finished.

  3. 3

    Record the four places your domain appears

    Webhook URL, domain verification, return and cancel URLs, statement descriptor. This list is what you will need the day the site's address changes.

  4. 4

    Test declines and timeouts, not just successes

    Use the published test cards for failure cases. Until a declined card produces something useful on screen, the checkout is not finished.

  5. 5

    Go live, buy something, then read the webhook log

    Swap in live keys, make one small real purchase and refund it. Confirm the money moved, the order recorded and the webhook actually delivered.

Built In

Fitted to every plan

  • Free SSL on every plan, reissued before the old one lapses
  • A 99.9% uptime target, watched around the clock
  • Nameservers, contacts, privacy and locks in one place
  • The registration recorded in your own details
  • DDoS traffic filtered at the network edge
  • A daily copy taken, with restores you run yourself
  • A desk staffed every hour of every day
  • Mailboxes answering at the name you hold
  • Renewal billed at the figure you registered at
  • Thirty days' money back on hosting plans, seven on reseller

Frequently Asked

Questions we field again and again

Payments are going through but orders stay unpaid. What broke?

The webhook. The provider is charging the card successfully and then failing to reach your site with the result, so nothing marks the order paid. It is almost always the callback URL still naming an old hostname, or a certificate the provider will not accept on the new one. Open the delivery log in the provider's dashboard, fix the URL, and replay the failed events — most providers will let you.

What do I have to change at the gateway when I move to a new domain?

Four things, and they are easy to miss because none of them announces itself. The webhook or callback URL. The domain verification, which has to be repeated for the new hostname before wallet buttons will render. The return and cancel URLs the customer is sent back to. And the statement descriptor, if it carries the old name. Update them before the switch, not after the first complaint.

A payment button has disappeared for some customers.

Check the provider's verified domain list first. Several wallet methods refuse to render on a hostname the provider has not confirmed you control, and adding a checkout on a subdomain counts as a new hostname. There is usually no error message at all — the option simply is not offered — which is why this is worth checking before you start debugging devices and browsers.

Can I take payments without running a full shop?

Yes. The same providers offer payment links and hosted checkout pages that take money with no catalogue behind them, which suits deposits, invoices and one-off services. You get the gateway's security posture without maintaining a shop you never needed — and the domain touch-points reduce to the return URL and the descriptor.

Keep reading

  • How to Create a Subdomain

    Create a subdomain, and understand what a new hostname implies for certificates and verification.

  • Web Hosting

    cPanel hosting on NVMe, with SSL, the migration and year one of the name included.

  • Magento Hosting

    Magento hosting, for catalogues that outgrow the usual shared arrangements.

Changing provider? Work through this checklist beforehand.

A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.

You get the checklist, followed now and then by a note on keeping a site responsive. Unsubscribe whenever you want; the privacy policy covers the rest.

Take the money. Keep the name steady.

Free SSL on every hostname, a 99.9% uptime target watched around the clock, and a desk that answers at any hour.

View Web Hosting plans