Virtual Terminal vs Payment Link: Which Should You Use? (2026)

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

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.

Stripe’s keyed entries can attract a higher rate at account level. Square charges 1.4% + 25p on UK cards for a link made in Square Payment Links, against 2.5% for a card typed into its Virtual Terminal or a link sent from it. SumUp’s Payments Plus plan costs £19 a month; SumUp’s payment links page lists one 2.50% rate and no separate Plus rate. Tyl’s payment gateway normally costs £14.95 + VAT a month, and Tyl settles the next business day. Worldpay publishes one eCommerce rate and no separate virtual terminal rate.

Rates sourced from provider websites in October 2026. SumUp is the exception, and not because a rate moved: it publishes no virtual terminal, so there is no keyed rate to quote. takepayments requires a direct quote.

Square is the one provider here where the channel changes the published price. A link made in Square Payment Links costs 1.4% + 25p on a UK card, while the same payment typed into its Virtual Terminal costs 2.5%, so on a £500 invoice you pay £7.25 rather than £12.50. Elsewhere the rate does not move: SumUp publishes no virtual terminal at all (the product address redirects to its help centre, that help centre lists no such product, and its remote route is payment links at 2.50%), and Tyl prices every channel at 1.39% + 5p. We read those pages on 14 and 15 October 2026. The difference that costs real money at every provider is the fraud liability, and that one is not close.

Square’s split is worth knowing before you send your first link. The 2.5% applies to a link sent from the Virtual Terminal, and the 1.4% + 25p to a link made in the separate Payment Links section of the dashboard, so the cheaper link is a matter of where you create it rather than which plan you are on.

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. Mastercard’s excessive chargeback programme applies once a merchant passes both a 1.5% chargeback ratio and 100 chargebacks in a month, so a small firm’s count rarely reaches the scheme threshold itself. The ratio still matters, and MOTO merchants push it up faster 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 already sits at 1.5%, the ratio Mastercard treats as excessive.

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 FCA’s guidance states that mail orders and telephone orders are out of scope of regulation 100 of the Payment Services Regulations 2017, 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.

In its National Payments Vision of November 2024, the Government said it would begin moving SCA requirements out of the technical standards and into FCA rules and guidance, for more agile, outcome-based regulation. The FCA and PSR’s joint response of 11 November 2025 confirmed that direction. 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

For solicitors and accountants, many clients are older or time-poor, so asking them to click a link adds friction. Tradespeople often pay within minutes of receiving the on-site SMS. A clinic’s virtual terminal takes the booking deposit in real time while the client remains on the line. For freelancers and consultants, putting the link in the invoice email is the lowest-friction route because payment need not wait for a call.

Telephone-order retail works differently: taking the card on the same call is the expected flow. Charity fundraising also depends on the call itself. On genuine donation calls, fraud-type dispute risk is lower than on commercial MOTO, and the chargeback liability structure is less punishing in practice.

B2B card buyers prefer a clean invoice link to calling an accounts team and reading out a card number. Bank transfer is typically lower-cost for high-value invoices, while card links suit smaller amounts.

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 such as Stripe and Square 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. SumUp offers payment links but no virtual terminal.

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

At Stripe and Square you apply online inside the same account. The traditional acquirers here publish no approval time: Worldpay says you can apply online in a few minutes and start once approved, and takepayments sets your pricing with a payment consultant first. 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, Square is the only provider here where the link costs less than the terminal. SumUp has no virtual terminal to compare against, so the choice there is a payment link at 2.50% or a card reader. Square charges 2.5% on its Virtual Terminal and 1.4% + 25p on UK cards through Square Payment Links, all in 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.

Frequently Asked Questions