A pay-by-link flow sends the customer a unique URL by SMS or email; they tap, see a hosted payment page, and pay. A hosted checkout sits inside your own customer journey — your website, your portal, your booking flow — and the payment page is embedded at the moment of purchase. Both keep card data off your servers. The difference is where the customer is when they pay, and which workflow each one actually fits.
When a payment link is the right tool#
Payment links work when the conversation is happening somewhere a checkout doesn't naturally live. A customer rings about an outstanding invoice — you send a link by SMS while you're still on the call. A web-chat agent quotes a deposit — they paste a link into the chat. A field engineer finishes a job and texts the bill from the van. Anywhere the buyer isn't currently sitting on a checkout page, a link bridges the gap.
The link itself is short-lived, single-use, and tied to a specific amount and reference — the buyer can't change either. Tap it, you land on a hosted page that looks like the merchant's brand, and the payment goes through 3D-Secure where the issuer requires it. Payment links are the right tool for late-stage chase, ad-hoc invoices, deposits, and anywhere the journey started by phone or chat rather than on a website. Advanced payment links add things like CRM integration, scheduled chasing, and rebooking on the same flow.
When hosted checkout is the right tool#
Hosted checkout is for customers who are already on your site. They've added something to a basket, picked a service, booked a slot. The checkout drops in at the natural payment step — branded as yours, hosted on the gateway's infrastructure, never touching your servers with raw card data.
The buyer doesn't switch context. They don't read a separate email, click a link, jump to a different page. They finish on the page they started on. For high-volume web sales, that flow consistency matters — every extra step costs you a percentage of completions.
Our customised web checkout is the embedded route — branded fields, configurable rules, the gateway handling the card capture. Secure web payments covers the same architecture for the broader online journey.
The compliance picture is identical#
Both architectures are PCI-compliant by the same mechanism: the card data never reaches your servers. The customer types into a field hosted by the gateway (or by a Level 1 service provider in front of it), the gateway tokenises, and you get back a reference. Your CRM, your invoicing system, your booking platform — none of them ever hold a PAN.
That keeps both flows under SAQ A rather than the much heavier SAQ D you'd attest to if you were taking card data through your own systems. The choice between link and embedded checkout doesn't change the compliance footprint. Either way, the cardholder data environment lives one layer down.
What each costs in friction#
Links cost a context switch. The customer reads "you've been sent a link" — they tap, they wait for the page to load, they pay. For a customer who was expecting a link (mid-call, mid-chat), that switch is invisible. For a customer mid-purchase on your website, asking them to wait for a link they then have to tap is a deliberate way to lose conversions.
Hosted checkout costs you the build. You're embedding a third-party payment page inside your own UI. That's a one-off integration, maintained over time, and it has to look like part of your brand or buyers get suspicious. The trade-off is that, once it's there, it's frictionless — the buyer never leaves the page they're on.
The honest read: links win on flexibility and speed-to-deploy. Embedded checkout wins on conversion-rate at the moment of sale. Most businesses end up running both, with each living where it earns its keep.
Who picks which#
If most of your sales start on a phone call, in chat, on a quote document, or after the fact — go with payment links. They drop into the workflow you already have. Plumbers, lawyers, recruitment agencies, B2B services, anyone whose first contact with the customer isn't a website checkout, will get more done with a link than a checkout page. Recurring payment setups can bolt the first card capture onto a link too, then reuse the token from there.
If you're running a website where customers self-select, click "buy", and expect to pay on the spot, go with embedded checkout. The link route would tell them to leave the journey and come back via email. They won't.
For most businesses that take payments across channels, the answer is both. Use the embedded checkout where the customer is already on your site. Use the link where the conversation got there first. Trying to force one to do the other's job is how you end up either annoying customers or losing them.
