Pay by Link & Secure Payment Links: The Complete Guide

A customer wants to pay you. They're not at a till and they're not on your website — maybe they're on the phone, maybe halfway through an email exchange. Pay by link solves that in one move: you send them a web link, they open a secure page, they type in their card details, you get a confirmation. No checkout to build, no app to install, and nothing for your agent to handle. For contact centres that last part is the whole point, because the card number never reaches the call. This guide covers what pay by link is, how it works, whether it's actually secure, what PCI DSS expects of you, and where it fits among the other ways you can take a payment by phone.

What pay by link actually is

Pay by link is a way to take a card payment by sending the customer a unique web address instead of using a checkout or a card machine. Open the link and you land on a secure payment page — usually hosted by the payment provider — showing the amount, what it's for, and a form for the card details. The customer pays, and you both get a confirmation. That's the whole mechanism. What makes it so widely used is that there's nothing to build: a link can be created in seconds from a provider's dashboard or API, and whoever sends it needs no technical skill at all.

One naming clash trips people up, so it's worth clearing early. "Pay by link" is the general method. "Link" with a capital L is also the name of a specific one-click wallet, and some people searching whether "Link" is safe are really asking about that wallet. This guide is about the general method — any payment taken by sending someone a link to a hosted card-entry page.

How pay by link works, step by step

The flow is short, which is most of the appeal.

1. You create the link in your provider's dashboard or through their API, setting the amount, a description, and — this one matters — an expiry. Some providers let you leave the amount open for the customer to set, which suits donations or part-payments.
2. You send it. Because it's just a URL, it goes wherever the moment calls for: email for invoices and quotes, SMS for fast collection, WhatsApp for an informal exchange, or a QR code on a printed invoice or a screen.
3. The customer opens it and lands on the hosted page, sees the amount and description, enters their card details or uses a digital wallet, and confirms.
4. You both get a confirmation, and your dashboard shows which links are sent, paid, or still outstanding — so reconciliation stays simple.

Because the customer pays on a page the provider hosts, you never build or maintain any payment infrastructure of your own. And the gap between "you owe me" and "you've paid" is about as small as it gets. Fewer steps usually means more people actually finish paying.

Why contact centres use payment links

This is where pay by link earns its keep, and it's the bit the payment-processor product pages skip past. The problem with taking a card over the phone is obvious once you say it out loud: the agent ends up hearing the card number, which drags the agent, the phone system, and the call recording into the scope of your PCI obligations. Sending a link steps around all of that.

The usual pattern is to send the link mid-call. The agent stays on the line, generates a link, fires it over by SMS or email, and the customer opens it on their own phone and pays on the hosted page. The agent never hears or sees a digit — they just watch a paid-or-declined result land in their system.

It's also the natural fallback when the keypad isn't an option. Not everyone is comfortable typing card details into their phone, and not every phone system carries the tones cleanly. A link moves the payment to the customer's browser instead and gets to the same place by a different road. And it works after the call, too. When someone rings to talk through a purchase or sort out a problem but isn't ready to pay there and then, you send a link afterwards and let them pay in their own time. For anything where payment follows a conversation — professional services, healthcare, insurance renewals — that's often the cleanest route.

Are payment links secure? What makes a link safe

A payment link is secure when it opens a hosted page run by a PCI-compliant provider. The card details are entered on that page, so they never touch your website, your agents, or your call recordings. That's the foundation: the sensitive data simply isn't in your environment to lose.

The risk worth managing sits on the sending side, and it's mostly about trust. Fraudsters send fake "payment links" too, and that matters more every year. UK Finance reported criminals stole £629.3 million in the first half of 2025 across more than two million confirmed cases, and authorised push payment scams — where a victim is tricked into paying willingly — made up £257.5 million of that, with around two-thirds originating online. Against that backdrop, a real payment link has to look unmistakably real. A few habits do most of the work: set an expiry so a link can't resurface months later, use single-use links where your provider supports them, brand the payment page with your name and logo, and only ever send a link to someone who's expecting it. A customer who's just been told "I'm sending you a link now" will trust it. A link arriving cold will — quite rightly — make people pause. We go into the consumer side of this in more detail in our piece on whether payment links are safe.

Pay by link and PCI DSS — the scope question

This is the question compliance officers actually care about, and the answer is a good one. Because the card data is captured on the provider's hosted page rather than anything you run, your agents, your website, and your call recordings all fall out of scope. In practice that means most merchants on this model can self-assess against SAQ A — the shortest of the PCI self-assessment questionnaires — rather than the far heavier SAQ D.

There's a recent change worth knowing. Under PCI DSS v4.0.1, in force since 31 March 2025, two requirements that used to live in SAQ A — 6.4.3 and 11.6.1, both about payment-page scripts and tamper detection — were removed from it. In their place the Council added an eligibility criterion: the merchant confirms their site isn't exposed to malicious-script attacks, which you satisfy either by getting confirmation from your provider that their solution protects the payment page, or by using techniques like Content Security Policy and Subresource Integrity yourself. For a pure pay-by-link setup, where the customer is redirected to the provider's page rather than paying inside a form embedded on your own site, this stays light-touch — but it's worth a line in your assessment.

Now hold that against the alternative. If an agent reads back a card number, or hears the customer say it aloud, the card data is in your environment, the recording captures it, and your scope grows to match. Taking the payment by link is, in the end, just a way of making sure none of that happens.

Pay by link versus other ways to take a phone payment

Pay by link is one tool, not the only one, and the right choice depends on the call in front of you. Here's how it sits against the main alternatives a contact centre has.

Method	How it works	PCI scope	Best for
Pay by link	Customer pays on a hosted page via a link you send	Low (SAQ A)	Async payments, follow-ups, customers who can't key digits
DTMF masking	Customer keys card details on their phone; the agent stays on the line and never hears the tones	Low	Real-time payment with the agent present, no channel switch
IVR self-service	An automated phone menu takes the payment, no agent	Low	High-volume, repeat, or out-of-hours payments
Manual keying into a virtual terminal	Agent types the card number into a browser form	High	Last resort — it puts the agent back in scope

In a live call where the customer has their card in hand and wants to pay now, DTMF masking keeps everything in one flow without switching channels. When the customer can't or won't use the keypad, or the payment is happening after the call, a link is the better fit. Manual keying should be the last resort, because it's the one option that puts the card number back in front of the agent.

How to send a secure payment link the right way

Most of what makes a link safe is in how you send it. A short checklist:

1. Set an expiry that matches the context — a few hours for an urgent payment, a few days for an invoice. A link that never expires is a standing risk.
2. Use single-use links where your provider supports them, so a paid link can't be reused.
3. Brand the payment page with your name and logo. Customers are right to be wary about entering card details, and a familiar page cuts both hesitation and abandonment.
4. Send through a channel the customer expects, and tell them it's coming — ideally on the call itself.
5. Never send to an unverified number or address, and never as a cold message.
6. Check your provider is PCI DSS Level 1 certified and that the hosted page meets current standards.

Get those right and pay by link is genuinely easy to use, and it gives customers real peace of mind that their card details are being handled properly.

References

• PCI Security Standards Council — FAQ clarifying new SAQ A eligibility criteria for e-commerce merchants. pcisecuritystandards.org
• PCI Security Standards Council — Document Library (SAQ A). pcisecuritystandards.org
• UK Finance — Over £600 million stolen by fraudsters in first half of 2025. ukfinance.org.uk
• UK Finance — Annual Fraud Report 2025. ukfinance.org.uk