Is a link payment safe? Yes — genuine payment links from a PCI-compliant provider are safe, because the card details are entered on the payment provider's own secure page, never on your device and never touching the sender's systems. The catch is that "genuine" is doing a lot of work in that sentence. Fraudulent links designed to look like payment requests have become one of the most common phishing vectors in the UK, so knowing how to tell a real one from a fake is the difference between a 30-second convenient payment and a drained current account.
We've built Paytia payment links to meet PCI DSS requirements since 2016. They're used every day by UK contact centres, charities, housing associations, and service businesses that need to send a customer a payment request by email or text without taking card details over the phone. This guide explains what a link payment method actually is, why the genuine ones are safe, how to tell them apart from the fake ones, and what your business should check before adopting them.
What is a payment link, and how does it work?#
A payment link is a unique URL that opens a hosted checkout page. A business creates the link inside their payment platform, sets the amount and an invoice or order reference, then sends the link to the customer by SMS, email, WhatsApp, or in a live chat. The customer clicks, lands on a payment provider's secure page, enters their card details, and the payment settles to the business's merchant account.
The customer never types card details into the business's own system. The business never sees the raw PAN. That's the whole point of a payment link, and it's why a properly built one sits in a different risk bucket from emailed PDF invoices that ask for bank transfers, or worse, agents reading card numbers down the phone.
If you're researching payment links as a payment method for your own business, the short answer to "are payment links safe" is yes — with three conditions. Use a PCI-compliant provider. Make sure the link opens on the provider's hosted domain, not yours. Give your customers a way to verify the link came from you. We expand on each of those below.
Are link payments safe? The short answer#
Yes, link payments are safe when three things are true. First, the link was issued by a legitimate business using a regulated payment provider. Second, the link opens on an HTTPS-secured page hosted by the payment provider, not the business. Third, the customer has a sensible way to verify the link before entering their card — either by recognising the sender, by cross-checking the amount, or by calling the business back on a trusted number.
When any of those three things is missing, the risk goes up. A link from an unknown sender, a page that isn't HTTPS, a "payment page" hosted on a strange-looking domain, an amount or invoice number the customer doesn't recognise — any of those are reasons to stop and verify before paying. We're going to walk through each of those checks in detail below.
How Payment Links Actually Work#
A payment link is a URL that takes you to a hosted checkout page. When a business sends you one, clicking it opens a webpage — usually hosted by your payment provider or a specialist payment platform — where you enter your card details and complete the transaction.
The critical point is that your card details are entered directly into the payment processor's secure environment, not into a form on the business's own website or system. The business never sees your raw card number. The payment processor handles the tokenisation, the card scheme authorisation, and the settlement. The business just gets told whether the payment worked.
This is actually a security advantage over some older payment methods. When you pay by phone and read your card number to an agent, the agent hears it, potentially records it, and types it into a system. With a payment link, none of that happens. Your card data goes straight into a locked-down payment environment.
Curious how Paytia fits in? Have a quick chat with us — we'll show you in 15 minutes whether we're a fit.
What Makes a Payment Link Secure#
Three things underpin the security of a legitimate payment link.
HTTPS Encryption
Any legitimate payment page will use HTTPS — the padlock icon in your browser's address bar. This means the connection between your browser and the payment server is encrypted. Nobody intercepting the traffic between you and the server can read your card details. If you ever land on a payment page that doesn't have HTTPS (or shows a security warning), don't proceed.
Tokenisation
When you enter your card number on a payment page, the payment processor doesn't store the raw digits. Instead, it immediately converts them into a token — a random string that has no intrinsic value. The token is what gets used for authorisation requests, stored in transaction records, and passed between systems. Your actual card number is protected behind a one-way cryptographic process.
This is why merchants aren't allowed to store your CVV under PCI DSS rules. The token is safe to store. The raw card number is not.
PCI DSS Compliance
PCI DSS — the Payment Card Industry Data Security Standard — governs how card data is handled across the entire payment chain. Any business sending you a payment link has to use a payment processor that is PCI compliant. The hosted checkout page you're directed to is subject to quarterly security scans, annual audits, and strict controls on who can access what.
This doesn't mean every payment link you receive is safe — it means the underlying technology, when used by a legitimate business with a compliant processor, is built to a defined security standard.
PCI DSS v4.0.1 and what changed for payment links in 2025#
If you're a business comparing payment link providers in 2026, ask them specifically about PCI DSS v4.0.1. The v4 standard went live in March 2024 with a transition period that ended in March 2025, so v3.2.1 is retired and v4.0.1 is the only version currently in force. A payment link provider that's still describing themselves as "PCI DSS v3 compliant" hasn't kept up, and that should give you pause.
The biggest change relevant to payment links is Requirement 6.4.3 and 11.6.1 — the rules around payment page integrity. Any script that loads on a payment page now has to be inventoried, justified, and monitored for tampering. That includes analytics, chat widgets, and tag managers. The reason is straightforward: client-side skimming attacks (Magecart-style) inject malicious JavaScript into checkout pages and quietly siphon card details. The new requirements force providers to detect that within hours, not weeks.
For a customer clicking a payment link, this is invisible. For a business choosing a provider, it's the difference between a provider who treats their hosted checkout as a critical security surface and one who treats it as a marketing landing page. We sit firmly in the first camp.
The Real Risk: Phishing Links That Look Like Payment Requests#
The danger with payment links isn't the technology — it's the fact that fraudsters can create fake pages that look convincingly like real checkout forms and then send links to them.
A phishing payment link typically arrives as an unexpected request. You might get a text claiming to be from a courier saying you owe a customs fee, or an email that appears to be from a supplier asking you to settle an invoice via a link. The page it takes you to might look professional. It might even mimic a real brand's checkout UI.
If you enter your card details on one of these pages, they go straight to the fraudster. There's no bank authorisation, no tokenisation. It's just a form that captures whatever you type.
How to Spot a Fake
Before entering card details on any payment link, check these things:
- Did you initiate this transaction? Legitimate payment links almost always follow a conversation you started — you placed an order, made a booking, received a service. Unsolicited payment requests from unknown senders are a red flag.
- Does the URL match the business? Look at the full URL in your browser's address bar. A payment page from a reputable provider sits on a domain you can recognise — often a checkout subdomain of either the business you're paying or the payment provider they use. A suspicious URL that barely resembles the business name, or uses free hosting, is a warning sign.
- Can you verify the sender independently? If you're not sure whether a payment request is genuine, don't click the link and don't call a phone number in the email. Find the business's contact details on their official website and call to ask whether the request is real.
- Is the payment amount what you agreed? If you're expecting to pay £120 for something and the link shows £1,200, that's not just a typo worth querying — it's potentially a fraud attempt.
The UK fraud picture: why payment link phishing is rising#
UK Finance's Annual Fraud Report has tracked authorised push payment (APP) fraud climbing year on year, and payment-link-style phishing sits inside that category. The pattern is consistent: a fraudster sends an SMS or email that looks like a legitimate payment request — a delivery fee, a parking charge, an invoice from a tradesperson the victim recently used — and the victim taps through and pays without checking.
The Payment Systems Regulator's reimbursement rules that came into force in October 2024 shifted some of the burden back to the sending and receiving banks, but they don't undo the fraud. They just decide who's out of pocket afterwards. Prevention is still the only good outcome.
What this means for businesses sending genuine payment links: you're operating in an environment where customers are increasingly suspicious. A request that arrives cold, with no context, looking like it came from a generic short URL, will trigger their fraud filter — even when it's perfectly legitimate. That's why the way you brand and verify your payment links matters as much as the underlying security.
How Paytia's Secure Code Feature Works#
Paytia includes a feature called Secure Code specifically designed to address the question of whether a payment link is genuine before a customer enters their card details.
When an agent sends a Paytia payment link, the customer doesn't just receive the link. They also get a four-digit verification code from the agent — spoken on the phone, or confirmed in writing through a channel the customer already trusts. When the customer opens the payment page, they enter that code before the card form appears. If the code matches, they see the amount, the merchant name, and the invoice reference, and only then do they enter their card details.
It's a small thing, but it closes the loophole that phishing relies on. A fraudster can spoof an SMS sender ID. They can clone a logo. What they can't do is reproduce a verification code that came from a live conversation the customer just had with the real business. If the code on the screen doesn't match what the agent gave you, you stop.
Where Secure Code sits in the wider Paytia stack
Payment links aren't a standalone product for us — they sit alongside DTMF masking for phone payments and channel separation for live-chat handovers. A typical Paytia customer uses all three depending on context: agent on the phone with a customer who can't find their card, send a link; customer reached the agent via webchat, hand them off to a separate payment channel; customer wants to pay there and then on the call, capture by DTMF. The link is one mode, not the whole answer. Contact centres use all three for that reason.
What to look for when you're choosing a payment link provider#
If you're a business deciding which provider to use, here's the checklist we'd run through ourselves:
- PCI DSS v4.0.1 attestation. Ask to see their current AoC. Date should be 2025 or later.
- Hosted payment page on the provider's domain. If they want to put the card form on your site "for branding," walk away — that drags your site into PCI scope.
- Verification mechanism for the customer. Something like Secure Code, or at minimum a clear sender brand and invoice reference the customer can cross-check.
- SMS sender ID you control. Random short codes are harder for customers to trust than your registered business name as the sender.
- 3D Secure 2 support. Strong Customer Authentication is mandatory for most UK transactions. Make sure 3DS2 is built in, not bolted on.
- Audit trail. Who sent which link, when, to whom, for what amount, and whether it was paid. If your provider can't answer that for any transaction in the last 12 months, that's a problem.
- Integration with your existing systems. CRM, helpdesk, billing. A payment link that copies and pastes from one screen to another isn't going to survive a busy day.
Payment links vs other payment methods#
Payment links aren't always the right tool. They're brilliant when the customer is at the other end of a phone, an email thread, or a chat conversation, and you need them to pay without you handling their card. They're less brilliant when the customer is sitting in front of you, or when you need an immediate authorisation while still on the call.
Versus phone payments with DTMF masking
If the customer wants to pay there and then while on the phone with your agent, DTMF masking is faster — the customer types the card digits on their keypad, the tones are intercepted before they reach the agent, and the payment authorises in real time. Send-a-link works too, but it ends the call or pauses it, and you lose conversion. We default to DTMF for in-call payments and links for everything else.
Versus emailed invoices with bank details
Old-school invoices that ask for a bank transfer are objectively worse from a fraud point of view. Bank details on a PDF can be tampered with mid-flight (this is the classic invoice redirection scam), and the customer has no easy way to verify them. A payment link with a hosted checkout, branded sender, and verification code is a measurable upgrade — both for the customer and for your reconciliation team.
Versus open banking / Pay by Bank
Open banking payments are the rising alternative, especially for B2B and higher-value B2C. They have strong customer authentication built in and they're cheaper than card. For some customers and some transaction types they're a better fit than card-based payment links. We're seeing customers use both side by side rather than one replacing the other.
Industry-specific rules to know#
UK and EU
Strong Customer Authentication under PSD2 (and PSD3 once it lands) means most card-not-present payments need a second authentication factor. 3D Secure 2 handles this automatically on a hosted payment page. If a payment link provider can't show you their 3DS2 flow, they're not ready for UK transactions.
US
SCA equivalents aren't mandated, but PCI DSS still applies, and individual states have layered their own privacy and notification rules on top. CCPA in California is the most stringent — if the merchant's customer data is in scope, the payment provider's handling of it has to support deletion and access requests.
Charities and housing
For charities, a payment link is often the right route for one-off donations where the donor isn't on a recurring schedule. The audit trail matters as much as the security — Gift Aid records need to tie back to a verifiable payment. Housing associations use them for rent arrears repayments where the resident is vulnerable and can't make the in-office trip; in that context the verification code matters more than the speed.
Common questions about whether sending a payment link is safe for the business#
Most of this guide has focused on whether payment links are safe to pay, but the other half of the question is whether they're safe to send. From the business's side, the risks are different.
The main one is reputational. If a customer thinks your payment link looks dodgy and doesn't pay, you lose the transaction and possibly the customer. The way to manage that is consistency — use the same SMS sender name, the same email-from address, the same payment domain, every single time. Customers learn the pattern. When you also offer a verification mechanism like Secure Code on top, you've moved the trust question off the customer's shoulders and onto the technology.
The secondary risk is PCI scope creep. If your CRM stores the payment link URL with the transaction amount visible, that's fine. If it stores any card data — even masked — you've pulled your CRM into PCI scope. Choose a provider whose audit trail keeps card data out of your systems entirely.
FAQ — payment link safety#
Is it safe to pay through a link sent by SMS?
Yes, if the link came from a business you're already dealing with, opens on an HTTPS page hosted by a recognisable payment provider, and shows the amount and reference you're expecting. No, if it arrived from a sender you don't recognise or asks you to enter card details on a strange-looking page.
How do I know a payment link is genuine?
Check the sender — does it match a conversation you've had with the business? Check the URL — does the domain belong to either the business or a payment provider you've heard of? Check the amount — is it what you agreed? If you're unsure, ring the business back on a trusted number (not a number in the email or SMS) and ask.
Are payment links PCI compliant?
Payment links from a regulated provider are built to meet PCI DSS v4.0.1, which is the current standard since March 2024. The card details get entered on the provider's hosted page, which sits inside their PCI environment. The business sending the link never sees the card data, which keeps them out of scope. "Payment links" sent from a homemade form on a business's own website are a different story — those put the business's site in scope, and you should be much more cautious about those.
Can a fraudster fake a payment link from a real business?
Yes — that's the core risk. Fraudsters can clone a brand's emails, spoof an SMS sender ID, and build a fake checkout page that looks convincing. The defence isn't pattern recognition (the fakes are getting too good); it's verification. A code or reference that came from a live conversation with the real business, that the fake link can't reproduce, is what breaks the attack.
What's the difference between a payment link and a Pay by Link?
No difference — they're the same thing. Different providers use different brand names: Pay by Link, Send-a-link, Payment Request, Quick Pay. The underlying mechanism is identical. A URL that opens a hosted payment page.
Can I see how much money was paid via a payment link?
Yes. Any decent provider keeps a full audit trail — link created, sent, opened, paid, settled, with timestamps and amounts. If your business reconciles to invoices, the payment link reference should tie back automatically. Our payment link audit log exposes this in a way your finance team can drop straight into their reconciliation.
Is a payment link safer than reading my card number over the phone?
Usually, yes. Reading a card number to an agent means at least one human hears it and potentially a call recording captures it. A payment link keeps your card details off the agent's screen and outside the business's systems. The exception is when the business has DTMF masking on their phone system — in that case the digits are intercepted before the agent hears them, and the security is comparable.
What should I do if I think I paid a fake payment link?
Call your bank immediately on the number on the back of your card and report the fraud. Don't ring any number from the email or SMS — that's how the second wave of the scam works. Your bank can block the card and start a fraud claim. Under the UK's APP fraud reimbursement rules introduced in October 2024, you may be entitled to a refund, but speed matters.
How long is a Paytia payment link valid?
By default our payment links expire in 24 hours, but the merchant can configure the expiry from a few minutes (for high-risk transactions where you want the customer to pay during the call) up to several days (for invoice-style requests). Expiring links is itself a security control — a link that no longer works can't be reused if it leaks.
Putting it all together#
If you're a customer wondering whether to click a payment link, the rule is simple: verify before you pay. If you're a business wondering whether to adopt them, the rule is also simple: use a PCI DSS v4.0.1-compliant provider, host the payment page off your domain, and give your customers a verification mechanism that closes the phishing loophole. Done that way, payment links are safer than the older payment methods they're replacing.
If you'd like to see how we've built ours, have a 15-minute chat with us. We'll show you a live link, walk through the Secure Code flow, and answer the awkward questions about scope and audit. No demo theatre, just the actual product.
