Both methods let you take a card without the customer in front of you. That is roughly where the similarity ends. The real question is not features. It is who keys the card data and what that means the moment a payment is disputed.
With a virtual terminal, your team types the card details the customer reads down the phone. With a payment link, you send a URL and the customer enters their own details on a hosted checkout page. That single workflow split changes your fraud liability, your PCI compliance category, and at some providers the rate you pay. This guide covers all three, including within-provider rate differences, and tells you which to use and when to run both.
For the full mechanics of how virtual terminals work, including PCI obligations and MOTO chargeback rules, see our virtual terminal guide. This article focuses on the comparison and the decision.
Virtual Terminal vs Payment Link at a Glance
| Feature | Virtual Terminal | Payment Link |
|---|---|---|
| Who keys in card data | Merchant (on customer’s behalf) | Customer (on provider’s hosted page) |
| Transaction type | MOTO — Card-Not-Present | E-commerce CNP (customer-initiated) |
| SCA / 3DS2 required? | No — MOTO is out of scope for SCA under UK PSRs 2017 | Yes, unless an exemption applies (low value, TRA, MIT) |
| Fraud liability on “unauthorised” dispute | Merchant bears it — no authentication record | Shifts to issuer on successful 3DS2 authentication |
| PCI DSS scope | SAQ C-VT (isolated device required) | SAQ A (31 questions — data goes only to provider’s hosted page) |
| Typical UK transaction rate | 1.39%–2.95% depending on provider; often higher than payment link rate | 1.5%–2.5% depending on provider; sometimes lower than VT rate at the same provider |
| Customer interaction required | None — customer reads card number; merchant does the rest | Customer clicks link, enters details, completes 3DS2 if prompted |
| Works when customer has no internet access? | Yes | No |
| Payment can be completed asynchronously? | No — requires merchant availability to key in | Yes — customer pays when convenient after receiving the link |
| Setup | Included in same account at most PSPs — no separate application | Included in same account at most PSPs — generate in under a minute |
Workflow: Who Handles the Card
With a virtual terminal, your team handles the card number. The customer reads it down the phone. Someone on your side types it into a browser-based portal, the processor encrypts it, and the authorisation runs through the card network. The customer never touches a payment interface. No authentication happens on their side. The issuing bank has no record of the cardholder actively consenting to the payment, because the merchant submitted it, not them.
With a payment link, you generate a URL from the provider dashboard in about thirty seconds and send it by email, SMS, or WhatsApp. The customer opens the link, lands on a hosted checkout, and enters their own card details. A 3DS2 challenge may appear: a push notification from their banking app, an SMS code, or a brief authentication screen. They complete it, the payment processes, and both sides get a confirmation. This time the issuing bank has a record that the customer initiated and authenticated the payment themselves.
That authentication record is the operative difference between the two workflows. Not a compliance technicality. The piece of evidence that decides who eats a fraud chargeback. The chargeback section below explains the practical fallout.
Refunds are merchant-initiated from the provider dashboard in both cases. Settlement timing is the same too: T+1 for Tyl, T+3 for Stripe, whichever the provider schedule says. From the customer’s perspective the end result looks similar. It is the path that differs, and the path is what carries the fraud liability consequence.
Cost Comparison Within the Same Provider
The rate question most businesses actually need to answer is not “Stripe vs SumUp”. It is: “if I already have a Stripe account, does a payment link cost me the same as a virtual terminal transaction?” The within-provider comparison turns out to matter more than the absolute rate, and that is where the findings are genuinely useful.
| Provider | Virtual Terminal rate (MOTO/keyed) | Payment Link rate | Rate differential | Notes |
|---|---|---|---|---|
| Stripe | 1.5% + 20p (standard UK cards); possible MOTO uplift | 1.5% + 20p — included in standard Payments pricing at no additional charge | Appears same on published pricing; MOTO surcharge possible | No monthly fee; no contract. Stripe does not publish a separate MOTO rate, but keyed entries can attract a higher rate at the account level. |
| Square | 2.5% (manually keyed) | 2.5% (payment links) | None | Square’s online store checkout is 1.4% + 25p — lower than payment links. VT and payment links are priced identically. No monthly fee; no contract. |
| SumUp | 2.95% + 25p (keyed/MOTO, PAYG plan) | 2.50% (payment links, PAYG plan) | Payment link is 0.45% cheaper per transaction | On a £500 invoice, that is £2.25 per transaction. Across 50 transactions/month: £112.50. Payments Plus (£19/month): payment links remain 2.5%; VT rate unchanged. |
| Tyl by NatWest | 1.39% + 5p (personal UK/European cards, under £50K/year) | 1.39% + 5p — same rate across all channels | None — channel-agnostic pricing | Monthly fee: £14.95 + VAT (6-month free promotion available, May 2026). Same-day settlement to linked NatWest account. 12-month contract. Explicitly no surcharges for different card types. |
| Worldpay | 1.0%–1.9% (volume-tiered); £15/month MMSC; £5/month PCI fee; 18-month contract | Included in Worldpay eCommerce package alongside VT — no separate rate published | Not disclosed separately | Both VT and Pay by Link bundled in Worldpay eCommerce at no separate charge. Rate differential not disclosed without a direct quote. |
| takepayments | Bespoke — quote required; domestic rates typically under 1% at volume | Included in same package; no separate rate | Not published | Both VT and pay-by-link included in £45–£65/month package. 12-month contract. Best suited to higher-volume MOTO businesses. |
Rates sourced from provider websites, May 2026. Worldpay and takepayments require a direct quote.
SumUp is the cleanest example of within-provider rate differentiation: 0.45% cheaper via payment link than virtual terminal on the PAYG plan. The gap exists because MOTO carries higher fraud risk and SumUp prices that into the VT rate. At 50 transactions of £500 average, that is over £100 a month for the same revenue. Big enough that any mixed client base should default to payment links wherever the customer can use one.
Square’s finding pulls in a different direction. Payment links and VT transactions cost the same at 2.5%, but Square’s online checkout sits at 1.4% + 25p. If you are deciding whether to build a basic product or service page so customers can pay through your website rather than via a link, that checkout rate is meaningfully lower. The payment link is the convenience option for the one-off transaction; the online checkout is the right route for repeatable volume.
Tyl’s channel-agnostic pricing strips out any cost reason to favour one channel over the other. The Tyl VT vs payment link decision becomes purely a workflow and fraud liability question, which is where the decision should sit anyway.
Chargeback Risk and Liability
This is the section most businesses read last and should read first.
When a cardholder rings their bank and says “I did not make this payment”, the bank initiates a chargeback. The outcome hinges on whether there is an authentication record. On a 3DS2-authenticated payment link transaction, the record exists: the card scheme can show the issuer that the cardholder completed an authentication step on their own device. On a MOTO transaction keyed through a virtual terminal, there is no such record. The merchant typed the card number; no authentication happened; the cardholder never touched a payment interface.
That asymmetry shapes representment, the process of disputing a chargeback. On a fraud-type dispute against an authenticated payment link, the merchant presents the 3DS2 authentication response code and liability shifts to the issuer. On a MOTO dispute, the merchant argues from call logs, verbal consent scripts, delivery confirmation, and transaction history. Those records matter. They are not the same as an authentication record.
The practical consequence is not that MOTO chargebacks are always lost. It is that fraud-type MOTO chargebacks take materially more effort to dispute and succeed less reliably. Visa and Mastercard flag merchant accounts for remediation when chargeback rates pass 1% of transactions. MOTO merchants reach that threshold more readily than 3DS2-authenticated e-commerce, because every “I didn’t authorise this” dispute lands on the merchant’s side of the ledger. A professional services firm processing 200 MOTO transactions a month and taking three “unauthorised” chargebacks — 1.5% — is already in the monitoring zone.
One important limit on the payment link advantage: 3DS2 covers fraud-type chargebacks. It does not cover service-type disputes. “The work was never done”, “the goods were not as described”, “I requested a refund and was refused” all remain the merchant’s problem regardless of how the payment was authenticated. For service businesses where fulfilment disputes are the main chargeback source, 3DS2 cuts fraud exposure but does not eliminate chargeback risk.
No independent UK statistic separately quantifies MOTO representment win rates against payment-link representment win rates with enough precision to cite a percentage. The structural logic of 3DS2 liability shift is documented in card scheme rules and confirmed by payment processors. The implication that MOTO merchants face a materially harder representment challenge on fraud-type disputes follows from that structure.
SCA: 3DS2 vs MOTO Out-of-Scope
The UK’s Strong Customer Authentication rules apply to electronic payment transactions initiated by the payer. Payment links sit squarely inside that definition: the customer submits the transaction through an electronic interface they control. Virtual terminal MOTO transactions do not, because the merchant submits the transaction and the cardholder is not interacting with any payment interface.
MOTO is not “exempt” from SCA the way low-value transactions or merchant-initiated transactions are exempt. It sits structurally outside the scope of the regulation. The UK Payment Services Regulations 2017 carve MOTO out entirely, which is why there is no 3DS2 challenge required, no exemption flag needed, and no SCA compliance issue with using a virtual terminal for phone payments. Your processor applies the MOTO indicator in the authorisation message automatically.
The practical implications run in opposite directions depending on what you need.
If you value compliance simplicity, the virtual terminal is straightforward: no SCA to manage, no exemption logic, no 3DS2 configuration. The trade-off is that the absence of authentication is precisely what removes your fraud liability protection on disputed payments.
If you value fraud protection on remote payments, the payment link is the right tool: 3DS2 applies automatically on hosted payment pages from all major UK PSPs, and exemption logic is managed by the provider, not by you. The trade-off is that you are asking the customer to complete an authentication step on their own device. Most handle that without friction in 2026; some find it confusing, and a small share abandon the payment without completing.
The FCA and PSR signalled in their joint response (November 2024) that they are moving toward more flexible, outcome-based SCA guidance. The core SCA obligations remain in force for 2026. Payment links continue to require 3DS2 (or a valid exemption), and MOTO continues to sit outside that scope.
Which UK Business Types Suit Each
| Business type | Recommended primary tool | Reasoning |
|---|---|---|
| Solicitor / accountant — deposits and staged payments | Virtual terminal (primary); payment link for digitally-comfortable clients | Many professional services clients are older or time-poor and pay over the phone during the initial engagement call. Asking them to click a link adds friction. Use payment links for clients who invoice themselves by email. |
| Plumber / electrician / builder | Payment link (primary); virtual terminal (fallback) | Send an SMS link before leaving site; most clients pay within minutes. The virtual terminal catches the client who calls the office later or is not comfortable paying online. |
| Private dental / physio / GP clinic | Virtual terminal (booking deposit); payment link (pre-appointment balance) | Take the deposit during the booking call via VT — payment happens in real time while the client is on the line. Send the balance as a payment link with the appointment reminder email or text. |
| Freelancer / consultant | Payment link in the invoice | The client has the invoice in front of them. A link in the same email is the lowest-friction route — they pay when they review the document, not only when you can both be on a call. |
| Telephone-order retail (specialist, bespoke) | Virtual terminal | The customer is placing an order by phone. Taking the card on the same call is the expected flow. Asking them to click a link they did not anticipate introduces unnecessary friction. |
| Charity telephone fundraiser | Virtual terminal | The donation moment is the call itself. Redirecting a donor to a link breaks the conversation and loses completions. Fraud-type dispute risk on genuine donation calls is lower than on commercial MOTO — the chargeback liability structure is less punishing in practice. |
| B2B account manager | Payment link for card; bank transfer for large sums | B2B buyers paying by card prefer a clean link in the invoice over calling an accounts team to read out a card number. For high-value invoices, bank transfer (BACS or Faster Payments) is typically lower-cost; card payment links make more sense for smaller B2B amounts. |
| Event organiser / personal trainer / tutor | Payment link | Deposits and session payments are naturally sent via link: booking confirmation email, WhatsApp, Instagram link-in-bio. No phone call required; payment arrives before the event or session. |
The pattern across most of these categories is consistent. Use a virtual terminal when the customer is already on the phone and immediate payment is part of the interaction. Use a payment link when the customer can reasonably complete the payment themselves at a convenient moment and the payment does not need to happen during the call.
The threshold for “can they use a payment link?” is lower than most businesses assume. A customer who can receive a text and has a smartphone can usually complete a payment link transaction inside two minutes. The businesses that genuinely need a virtual terminal as their primary tool are those whose clients are on the phone, who are not digitally comfortable, or where the payment is expected in the moment of the interaction. That is a real category, but it is smaller than the set of businesses currently defaulting to a virtual terminal for every remote payment.
Setup and KYB Requirements
For most UK businesses, setting up virtual terminal access and payment link access is not two decisions. It is one. At PSP aggregators — Stripe, Square, SumUp — both sit inside the same account, with no separate application, no extra underwriting, and no additional fee. A Stripe account includes both the Dashboard virtual terminal and the ability to generate Payment Links. Same with Square and SumUp.
KYB requirements are the same for both channels at any provider:
- Legal business name and Companies House number (limited companies) or evidence of trading activity (sole traders)
- Director and UBO identity verification — passport or driving licence
- Proof of address for each director, dated within three months
- Business bank account details for settlement
- Business description and projected monthly volumes
- A basic web presence — most acquirers require a URL even for phone-only businesses to verify trading legitimacy
PSP aggregators usually approve same-day or within hours. Traditional acquirers — Worldpay, Tyl, takepayments — take two to ten business days and ask for three months of business bank statements. Both virtual terminal and payment links are included in any package; you do not apply for each channel separately.
One operational nuance worth checking before you rely on either. At Stripe, manually keyed transactions sometimes need a short account review to enable, particularly for new accounts or accounts flagged into elevated-risk categories. The thing you do not want is a client on the phone, ready to pay, while you discover the Dashboard virtual terminal has not been turned on yet. Run a small test transaction before the first live call. The same goes for payment links: generate one and walk through the customer flow yourself before sending it to a client for the first time. Most setup problems show up in the test transaction, not in the production transaction the next morning.
One more thing acquirer onboarding rarely flags in the sales call: the projected monthly MOTO volume on the application form is not a throwaway number. Underwriters use it to set your initial limits, and a figure that looks comfortably under your real activity will need renegotiating once your actual volume runs higher. The renegotiation rarely lands in your favour. Quote the realistic number, not the conservative one.
Customer Experience and Accessibility
The customer experience question is not which looks more professional. It is which friction level the specific customer can absorb.
A payment link asks the customer to do something: receive a message, click a link, open a checkout page, enter their card details, and complete a 3DS2 step if one appears. For most customers in 2026, that flow is unremarkable — the same as paying for anything online. For an 80-year-old client who has dealt with the same accountant for twenty years and prefers to pay over the phone, it is a barrier. Send him a link and you get a call back asking what it is, which takes more staff time than just taking the payment would have. The friction cost is real.
The virtual terminal asks nothing of the customer. They read the card number. That is the entire interaction on their side. It is the most accessible remote payment channel available to businesses: no device required, no internet connection, no authentication step to complete. For professional services firms with older or less digitally-comfortable clients, that accessibility is a genuine operational advantage, not a feature list item.
For digitally native clients — freelancers’ typical buyers, most B2B tech-sector contacts, anyone who found you through your website or social media — a payment link is the expected channel. Asking them to read card details over the phone to a stranger will feel less intuitive, not more. The right tool is the one that matches the client’s mental model of how payments work.
The 3DS2 authentication step on payment links is worth noting separately. Most customers encounter it without issue; a push notification from their banking app takes five seconds. A small share find it confusing, particularly if they are not enrolled in their bank’s app-based authentication. A failed or abandoned 3DS2 step produces an incomplete payment that needs a follow-up: resend the link, or at that point offer the virtual terminal instead. For businesses processing significant volumes of payment links, some percentage of links will not complete on first attempt. That is an operational reality to plan for, not a reason to avoid payment links, but it is a reason to keep the virtual terminal available as a fallback.
When to Use Both Together
For most businesses, the answer is not “virtual terminal or payment link”. It is “virtual terminal for these clients, payment link for those, and know which is which before you need to decide”.
The practical split in most professional services and field services businesses looks like this. Payment links become the default for all new clients and digitally-comfortable clients: sent in the booking confirmation, in the invoice email, or as a follow-up text after a job. The virtual terminal becomes the fallback for clients who call to pay, who are not comfortable with online payment pages, or where the payment needs to happen in real time during a phone interaction.
Running both costs nothing extra at PSP aggregators — both come bundled in the same account. There is no contractual or operational barrier to using each where it fits.
The operational discipline worth building is a default shift toward payment links wherever feasible, because it transfers fraud liability to the issuer and keeps PCI scope at SAQ A rather than SAQ C-VT. Over time, that default moves more of your payments onto the lower-risk channel without any change to your provider, contract, or pricing.
One sequence that works particularly well in professional services: take a deposit via the virtual terminal at the point of booking — the client is on the phone, ready to pay, and the immediate payment is part of the service interaction. Send the balance invoice by email with a payment link when the work is complete — the client pays when they review the invoice, at their convenience, with no need for a further call. The VT handles the moment where immediacy matters; the payment link handles everything else.
Final Verdict: Which Should You Use?
For most UK businesses taking remote card payments, the payment link should be your default and the virtual terminal your fallback — not the other way around, which is how most businesses currently run it. The reason is liability, not cost. A 3DS2-authenticated payment link shifts fraud-type chargeback liability to the issuer and keeps you at PCI SAQ A; a keyed MOTO transaction leaves both on your side of the ledger. On a mixed client base, default to the link wherever the customer can use one, and reserve the terminal for the moments that genuinely need it.
Keep the virtual terminal as the primary tool only where your clients are phone-first, not digitally comfortable, or expect to pay in the moment of the call — professional services with older clients, telephone-order retail, charity fundraising. There the terminal’s zero-friction accessibility is a real operational advantage, and the lower fraud-dispute risk on genuine phone interactions softens the liability trade-off.
On provider choice, the within-provider gap matters more than the brand. SumUp charges 0.45% less via payment link than via the terminal, so a link-first default saves real money. Square prices both channels the same but offers a cheaper online checkout for repeatable volume, and bundles everything into a free, no-contract account. Tyl by NatWest prices every channel identically, so the choice there is purely workflow. For higher-volume MOTO businesses, takepayments negotiates bespoke rates worth a quote.
The bottom line. Default to payment links for the fraud-liability shift and lighter PCI scope; keep a virtual terminal available for phone-first clients and in-the-moment payments. Both come bundled in one account at Stripe, Square and SumUp, so the real decision is per-customer, not per-provider — and on most providers the cost gap between the two is smaller than the liability gap.
Frequently Asked Questions
Yes, materially. A virtual terminal places you in SAQ C-VT, which requires your terminal computer to be properly isolated from other systems — not used for general email, browsing, or file sharing. If your setup is a shared office laptop, you may not qualify for SAQ C-VT and could fall into SAQ D (251 controls). A payment link places you in SAQ A: 31 questions, minimal controls, because card data goes directly to the provider’s hosted page and never passes through your environment. For any business with ambiguity about its virtual terminal setup, shifting to payment links wherever feasible meaningfully reduces compliance burden. See our virtual terminal guide for the full SAQ C-VT requirements, including the new PCI DSS 4.0 obligations effective March 2025.
No, and you would not want to. 3DS2 applies automatically on payment links via hosted checkout pages from all major UK PSPs. Exemptions exist (transactions under £30, TRA exemptions where fraud rates are within threshold), and your provider handles these automatically for eligible payments. You cannot manually skip 3DS2 for a standard payment link transaction. The authentication step is precisely what shifts fraud liability to the issuer on a disputed payment. If you need to process a payment without 3DS2 because the customer is on the phone with you right now and cannot complete an online step, use the virtual terminal for that specific transaction.
On fraud-type disputes (“I did not make this payment”) where 3DS2 ran and the customer authenticated, liability shifts to the issuing bank. The authentication record is the decisive evidence: the card scheme shows the issuer that the cardholder completed the authentication step on their own device, and the issuer typically bears the liability rather than the dispute landing on you. The protection does not apply to service-type disputes — “I did not receive the goods”, “the service was not as described”, “I requested a refund and was refused”. Those remain the merchant’s responsibility regardless of how the payment was authenticated. MOTO transactions on a virtual terminal have no equivalent protection on any dispute type, because there is no authentication record to present.
No, it depends on the provider. SumUp charges 0.45% more for manually keyed VT transactions (2.95% + 25p) than for payment links (2.50%) on the PAYG plan, reflecting higher fraud risk priced into the MOTO rate. Square charges the same for both (2.5%). Tyl by NatWest prices all channels identically at 1.39% + 5p. Stripe’s published rate appears the same for both, though a MOTO-specific surcharge may apply — confirm directly if you process significant MOTO volume. The cost difference between the two methods, within the same provider, is usually smaller than businesses expect. The fraud liability difference is usually larger.
Yes. Most UK providers support sending payment links via SMS, email, WhatsApp, or any messaging platform. Stripe Payment Links generate a URL you paste anywhere. Square and SumUp support SMS delivery from the dashboard. Tyl by NatWest explicitly lists SMS, email, and WhatsApp. SMS tends to produce higher completion rates than email for payment links — customers see the message on the lock screen and often pay within minutes. Include your business name in the message body so the link does not look like a phishing attempt; SMS payment links from unrecognised numbers do get abandoned. Sending from a consistent number your client recognises helps.
Standard payment links are single-use or time-limited, not recurring. For recurring charges, you need card tokenisation (the customer pays once, you save the token, future charges run without them re-entering details) or a subscription billing product. Stripe, Square, and SumUp all support card-on-file tokenisation as a separate feature from one-off payment links. A virtual terminal with tokenisation can also support recurring billing: the customer gives their card number once over the phone, and subsequent charges run automatically against the stored token without further calls. Confirm tokenisation availability and any additional fees before building a recurring payment model around either channel.
Yes, with one cost caveat. Corporate and purchasing cards process through the same hosted checkout as consumer cards, so the link itself works. The cost difference is in interchange: corporate cards carry higher interchange rates, which providers pass through on interchange-plus contracts (Adyen, some Worldpay agreements) or absorb and blend on flat-rate pricing. For high-value B2B invoices, bank transfer (BACS or Faster Payments) is typically the lower-cost channel. A payment link makes more sense for smaller B2B amounts where the convenience of card payment outweighs the fee difference, and where the client’s procurement process does not support direct bank transfer for small purchases.
Methodology and Disclosure
How we did this. We built this guide from the published UK pricing and product documentation of the providers named (Stripe, Square, SumUp, Tyl by NatWest, Worldpay and takepayments), the UK Payment Services Regulations 2017 (which place MOTO outside SCA scope), Visa and Mastercard 3DS2 liability-shift and chargeback-monitoring rules, the PCI DSS SAQ categories (SAQ A vs SAQ C-VT, including PCI DSS 4.0), and the FCA/PSR joint SCA response of November 2024. The within-provider rate comparison is the analysis we think matters most, so it leads the cost section.
What this guide does not do. Worldpay and takepayments rates are bespoke and require a direct quote, so the figures shown are indicative; MOTO surcharges and account-level rates vary, so confirm your own VT and payment-link rates in writing. No independent UK source separately quantifies MOTO versus payment-link representment win rates, so the liability comparison is drawn from the documented structure of 3DS2, not a cited percentage. Rates and rules change — we last checked against provider and regulatory sources in May 2026.
Disclosure. BusinessExpert is reader-supported. Some links on this page are affiliate links — Square, SumUp and takepayments — and if you click through and buy, we may earn a commission at no extra cost to you. The other provider links are direct, non-affiliate links. Affiliate relationships never affect our editorial assessments, the rates we report, or which providers we name. See our editorial policy.