Checkout engineering · Beginner · an hour, unhappy paths included
How to take payments online — Keep the Card Off Your Server, and the Gateway Script Off the Critical Path
The happy path works, which tells you nothing about what a shopper sees when their bank throws a 3-D Secure challenge and your webhook times out.
The short answer
Let the gateway hold the card. Tokenised or hosted fields mean the card number is captured by the provider's own script and never touches your server, which keeps you in the lightest PCI bracket instead of the heavy one — and an SSL certificate, on its own, has nothing to do with that. Encryption protects the connection; scope is decided by where card data travels.
Two things then decide whether the checkout actually works. The unhappy paths — declines, 3-D Secure challenges, timeouts — which providers publish test cards for and almost nobody exercises. And the webhook, which is what records the order when the shopper closes the tab before being redirected back.
By the HostingFast team · Reviewed 24 August 2026
Beginner
Reader level
an hour
Time to allow
5
Stages in order
24/7
Help on shift
An hour, most of it spent deliberately failing. This assumes you can read a network waterfall and a webhook log, because those are the two places a checkout tells you what it really did.
Merchant verification is the slow step and it runs on somebody else's timetable — days rather than minutes. Start it before you need it, and do the technical work below while it processes.
Where the card data goes decides your scope
With tokenised or hosted fields, the provider's script renders the card input and exchanges the number for a token on their own infrastructure. Your server receives the token and never the number. That is the difference between the lightest self-assessment bracket and one that involves considerably more of your year.
Building your own card form reverses that: the number now passes through your application, your logs and your error reporting, and every one of those becomes in scope. The certificate on your domain does not change any of it — it protects the connection, not the storage or the handling.
The gateway script is a third party on your checkout
The provider's JavaScript is a third-party dependency loading on the page where you least want a delay. Load it asynchronously and only on the pages that need it — a payment script enqueued site-wide is on your blog posts for no reason at all. Check with the Network panel on a non-checkout page.
Then measure the checkout itself. It is uncacheable by definition, so its first-byte figure is real PHP and database work, and the gateway script's evaluation time sits on top of that. Record both before launch so you can tell later whether a plugin update made things worse.
Test the failures, because customers will find them
Providers publish test card numbers that decline, that trigger a 3-D Secure challenge, that report insufficient funds, that time out. Run every one and read what the shopper sees. A checkout is only finished when the failure messages are specific enough to act on — 'payment failed' sends the customer to a competitor rather than to their other card.
Test the 3-D Secure flow on a phone as well as a desktop, since the challenge frequently opens in a way that behaves differently on mobile. That is also where most of your card traffic is, which makes it the version worth getting right.
Webhooks record the order when the browser does not
The redirect back to your site is not a reliable event. Shoppers close the tab, lose signal, or get held on the bank's page long enough to give up. The webhook is what tells your store the payment succeeded regardless, so confirm it is configured, that your endpoint returns quickly, and that the provider's dashboard shows deliveries succeeding rather than retrying.
Then go live properly: swap the sandbox keys for live ones, make one small genuine purchase, and refund it. Confirm the money moved, the order recorded and the refund landed before you announce anything. Free SSL is already in place and renewing itself, so the padlock is not a launch task.
The checkout's half of the stack
A checkout cannot be cached, so it runs on PHP and the database every single time — which is why NVMe storage and a current PHP release are doing more for your conversion rate here than any front-end tweak. Free SSL is issued and renewed for you on every plan.
Mailboxes on your own domain come as part of the plan — email is included rather than sold back to you at checkout.
- NVMe under the database, where an uncacheable checkout runs
- Free SSL on every plan, reissued before it can expire
- Per-site PHP switching, so the gateway plugin gets a current runtime
- Staging clones for rehearsing a gateway update
Why HostingFast
Standard on every plan
Scope explained by mechanism
Where the card number travels decides your PCI bracket, and this page says so instead of pointing at a padlock.
The gateway script measured
A third-party dependency on the most important page you own, loaded asynchronously and only where it is needed.
Failures rehearsed
Declines, 3-D Secure and timeouts run with the provider's own test cards, on a phone as well as a desktop.
Webhooks treated as the source of truth
The redirect is unreliable; the webhook is what records the order when a shopper closes the tab.
Verification started early
Merchant checks run on somebody else's timetable, so they begin before launch week rather than during it.
A real transaction, then a refund
One live purchase and one live refund, both confirmed, before anything is announced to customers.
Quick Start
From order to online
- 1
Start merchant verification now
Business details, bank account, identity documents. It takes days rather than minutes and it is the only part of this you cannot compress.
- 2
Choose tokenised or hosted fields
The provider's script captures the card and hands you a token. The number never reaches your server, your logs or your error reports — which is the whole point.
- 3
Install the extension and place the script
Official plugin, sandbox keys, and the gateway script loading asynchronously on checkout pages only. Confirm it is absent from a blog post.
- 4
Run every published failure card
Decline, insufficient funds, 3-D Secure, timeout. Read what the shopper sees each time, on a phone as well as a desktop.
- 5
Prove the webhook, then go live and refund
Check deliveries are succeeding in the provider's dashboard. Then swap to live keys, buy something small yourself, and refund it.
Built In
Loaded onto every plan
- Free SSL on every plan, reissued automatically before it can expire
- NVMe SSD storage on every tier, including the entry plan
- Per-site PHP version switching from the control panel
- LiteSpeed caching compiled into the server, not bolted on by plugin
- Staging environments for rehearsing a change before it ships
- Daily backups on every plan, with restores you run yourself from the panel
- Email addresses that run on your own domain name
- DDoS filtering absorbed out at the network edge
- In-place account upgrades, with no migration when you change plan
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
Where should the gateway script load so it does not slow the checkout?
Asynchronously, and only on the pages that need it. Many payment plugins enqueue their script site-wide by default, so it downloads and executes on blog posts and contact pages for no benefit at all. Check with the Network panel on a non-checkout page, then restrict it and re-measure the checkout's own first-byte and script evaluation figures.
How do I test a declined card and a 3-D Secure challenge?
Every serious provider publishes test card numbers for exactly these cases — decline, insufficient funds, 3-D Secure required, timeout — usable while your keys are in sandbox mode. Run all of them and read the message the shopper gets. Do the 3-D Secure one on a phone too, because the challenge often behaves differently there and that is where most card traffic is.
If the webhook fails, does the order still get recorded?
That depends on whether the shopper made it back to your site, which is exactly why the webhook exists. Browsers get closed, signal drops, and bank challenge pages hold people until they give up. Check the provider's dashboard shows deliveries succeeding rather than retrying, and make sure your endpoint responds quickly enough not to time out under load.
Does having SSL put me outside PCI scope?
No. The certificate encrypts the connection; your scope is determined by where card data travels and is stored. Tokenised or hosted fields keep the number on the provider's infrastructure and keep you in the lightest self-assessment bracket. A hand-built card form on your own site puts the number through your application and logs, and pulls the full burden onto you.
Keep reading
How to Create a Subdomain
Point blog.yourdomain or app.yourdomain at its own document root, with the certificate covering it — beginner, roughly 5 minutes.
How to Enable LiteSpeed Caching
Switch the server's cache engine on and prove it is returning hits by reading the response header — beginner, roughly 20 minutes.
Best LiteSpeed Hosting
Weighed up properly, with a verdict at the end rather than a table of ticks.
Web Hosting
cPanel hosting on NVMe behind a LiteSpeed cache — SSL, migration and a year-one domain included.
Magento Hosting
Plans with the memory and PHP headroom Magento genuinely requires.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Run the uncacheable page on NVMe.
Free auto-renewing SSL, NVMe under the database, per-site PHP control, and engineers on shift whatever hour the gateway misbehaves.
View Web Hosting plans