Quick answer: a virtual terminal is a browser-based payment form where a member of staff keys in a customer's card details, usually read out over the phone. It's a legitimate way to take MOTO (mail order / telephone order) payments and it can be operated compliantly. The catch is scope: because the agent hears the card number and types it, the workstation, the network it sits on, the phone system, any call recordings and the staff themselves all fall inside PCI DSS scope. For occasional payments that trade-off can be reasonable. At call volume, the secure alternatives keep the card number out of your environment entirely: the caller types it on their own phone keypad and the digits route straight to the payment gateway, or the caller pays through an automated IVR flow, or you send a payment link and they pay on their own device.
This guide covers what a virtual terminal actually is, what using one means for your PCI DSS validation, when it's genuinely the right tool, and the patterns to move to when it isn't. It also covers the question a lot of businesses arrive here with: what to do when the virtual terminal that came with your merchant account no longer fits how you work.
What a virtual terminal is
A virtual terminal is the software equivalent of a card machine. Instead of a customer tapping a physical terminal, a person on your side logs into a web page, types in the card number, expiry, security code and amount, and submits the payment. The customer is usually on the phone reading the details out, though the same form handles mail order and standing instructions.
Most payment gateways and acquirers include one. If you have a merchant account, there's a good chance a virtual terminal came with it, which is exactly why so many phone-payment operations start there: it's already paid for, the login already exists, and any member of staff can use it with no training beyond "type what the caller says."
Businesses use virtual terminals because they solve a real problem. Phone orders, deposits, invoice payments and balance collections all complete on a call, and the virtual terminal turns any desk into a point of sale. The problem is not that they don't work. The problem is what they do to your compliance surface.
What a virtual terminal costs you in PCI terms
PCI DSS applies to every system that stores, processes or transmits cardholder data, plus everything connected to those systems. A virtual terminal payment runs the card number through more of your business than any other channel:
The agent hears the card number. Spoken card data puts the telephony environment in scope: your phone platform, SIP trunks and call routing all carry it.
The agent types the card number. The workstation running the virtual terminal is processing cardholder data, so it's in scope, along with the network segment it sits on and everything connected to it.
Recordings capture it. If call recording is running while the caller reads out their card, that recording is stored cardholder data. Storing the security code after authorization is prohibited outright, in any form, recording included.
Your people are part of the surface. Staff who hear and see card numbers bring vetting, training and monitoring requirements with them.
None of this makes virtual terminals non-compliant. It makes them expensive to operate compliantly. Where a given setup lands on the validation spectrum depends on the details and is worth confirming with your acquirer or assessor, but the direction is consistent: keying in spoken card numbers typically pushes you toward the heavier self-assessment routes (often SAQ C-VT where the terminal meets specific isolation conditions, SAQ D where it doesn't), while patterns that keep card data out of your systems typically support the lighter end.
When a virtual terminal is genuinely fine
Honesty matters here, because the virtual terminal is often the right answer:
Low volume. A business taking a handful of phone payments a month can usually meet the controls without the scope becoming a burden. A dedicated, isolated workstation, no call recording during payment, and staff who know not to write anything down goes a long way.
Occasional MOTO orders. If phone payment is the exception rather than the workflow, replacing the virtual terminal with new call infrastructure is more project than the problem deserves.
No call recording requirement. A lot of virtual terminal risk concentrates in recordings. If you don't record calls and don't need to, one of the harder problems disappears.
The calculation changes when phone payments are a daily operation. A team taking cards all day means workstations, recordings, phone systems and people permanently inside the card data environment, with the assessment and audit weight that brings. At that point the question stops being "how do we secure the virtual terminal" and becomes "why is card data entering our systems at all."
The secure alternatives
Three established patterns take payments on a phone call, or from one, without the card number ever reaching your staff or systems.
Agent-assisted DTMF capture
The agent stays on the call. When it's time to pay, the caller types their card number on their own phone keypad. The keypad tones (DTMF) route directly to the payment gateway; the digits never reach the agent, and their screen shows only masked progress. The conversation continues, the recording can keep running, and the card number never enters your phone system, workstations or recordings. This is the closest replacement for a virtual terminal, because the shape of the call doesn't change: same agent, same conversation, payment completed before hanging up. See how DTMF payment capture works and what agent-assisted payments look like in practice.
IVR self-payment
The caller pays through an automated keypad flow with no agent on the line: they call in or are transferred, enter a reference and their card details, and get a confirmation. Because no member of staff is involved, the routine volume (bill payments, balances, renewals) stops consuming agent time as well as leaving your PCI surface. IVR payments cover this pattern in detail.
Payment links
Instead of taking card details at all, send the customer a link by SMS or email and they pay on their own device. This is the natural fit for mail order, invoicing and any payment that doesn't need to complete live on the call. It's also the recovery path when a live payment fails: card in another room, call dropped, caller wants to check with someone first.
Side by side
Virtual terminal | Agent-assisted DTMF | IVR self-payment | Payment link | |
|---|---|---|---|---|
Card data enters your systems | Yes (heard and typed) | No | No | No |
Recording can run throughout | Not without pause-and-resume | Yes | Yes | Yes |
PCI validation weight | Typically heavy | Typically light | Typically light | Typically light |
Agent on the call | Yes | Yes | No | Optional |
The validation rows are directional, not a guarantee: your exact SAQ route depends on your setup, so confirm it with your acquirer or assessor. Most phone-heavy operations end up running agent-assisted capture for conversations, IVR for routine volume, and links as the fallback.
Looking for an alternative to your bank's virtual terminal?
A common version of this search isn't "what is a virtual terminal" but "how do I replace the one I've got." Many acquirers and gateways bundle a virtual terminal with the merchant account, and it served its purpose until volume grew, call recording became a requirement, or a PCI questionnaire asked hard questions about agent workstations.
The instinct is often to switch providers entirely. Usually you don't need to. The virtual terminal and the merchant account are separate things: the merchant account is where your money settles and where your rates live, and the virtual terminal is just one way of getting card details to it. In most cases you can keep the merchant account and gateway you have and put compliant capture in front of it.
That's the model Shuttle is built on. Shuttle works with 40+ payment gateways, so where yours is among them, the payments your team takes by keypad capture, IVR or payment link settle through the merchant account you already have, on the rates you already negotiated. Voice capture works on many supported gateways, and payment links extend the coverage further. Where that is the case, nothing about your acquiring relationship has to change for the card data to stop passing through your staff.
Replacing the virtual terminal a specific provider gave you
A lot of people arrive here from a narrower search than "what is a virtual terminal." The searches are specific: alternatives to a Worldpay virtual terminal, an Adyen one, an Authorize.net one, or the one bundled with a merchant services account from a bank or provider such as Wells Fargo, Bank of America, PNC or Dharma.
Spreedly turns up in the same searches, but it is worth separating out. Spreedly is an orchestration layer and a vault rather than a virtual terminal, so if that is where you are starting, the key-in form you are trying to replace belongs to the gateway underneath it, not to Spreedly.
The provider name changes. The answer rarely does.
The compliance problem is not a property of any particular product. It follows from the workflow. Any interface where a member of staff hears a card number and types it puts your agents, workstations, network segment, phone platform and call recordings inside PCI DSS scope. A better-built virtual terminal is still a virtual terminal. Switching to a different provider's version of the same form moves the problem rather than solving it.
So the useful question is not "whose virtual terminal is best." It is "does card data need to pass through my staff at all." Two routes follow from that:
Keep the provider, change the capture. If your gateway is one of the payment providers Shuttle supports, you keep it and change only how card details reach it. Your merchant account, your negotiated rates and your settlement stay exactly where they are, and the card number stops travelling through your people and systems. This is the option most people searching for an alternative have not considered, because it is not framed as an alternative. It is a change to one layer rather than a change of provider. If your gateway is not supported, the same three patterns still apply, but you would be changing provider as well, which is a separate exercise.
Move the volume that does not need an agent. Renewals, balances, invoice payments and payment plan instalments rarely need a person on the line. Routing those to IVR or a payment link takes them out of your PCI surface and out of your agents' day at the same time.
If you do genuinely need to change provider as well, that is a separate exercise with its own risks around stored cards and subscriptions. See how to switch payment providers for the migration mechanics.
How Shuttle replaces the virtual terminal workflow
Shuttle provides the compliant phone patterns through one layer:
Agent-assisted capture and IVR self-payment run on Twilio's voice infrastructure. Shuttle is Twilio's chosen provider to enable Twilio Pay for many payment gateways.
Card details are tokenized with the payment gateway itself. Shuttle holds no card vault of its own, so there is no new place where card data accumulates.
Your gateway stays. Payments route through your existing merchant account, so switching how you capture doesn't mean switching who you process with.
The fallbacks are built in. Payment links by SMS or email, and bank payments on the call, so a failed card moment doesn't become a lost payment.
Repeat payments without re-keying. Because tokenization happens with the gateway, follow-on payments run against the stored token rather than another round of card entry, so you can build repeat billing or a payment plan into your own workflow.
For agents, the change is smaller than it sounds: same call, same conversation. Instead of typing what they hear, agents trigger the secure capture step from your phone system or desktop, once that trigger has been wired in on your side, and the caller types their card number on their own keypad.
Virtual terminal payments FAQ
Is a virtual terminal PCI compliant?
A virtual terminal can be operated compliantly; the product itself isn't the issue. The issue is scope: because staff hear and key in card numbers, your workstations, network, phone system, recordings and people are all inside PCI DSS scope and must meet the applicable controls. Compliant, yes. Lightweight, no.
What SAQ does a virtual terminal put me in?
Typically SAQ C-VT or SAQ D, depending on how the terminal is set up. SAQ C-VT applies to specific configurations (a validated virtual terminal on an isolated workstation, no electronic cardholder data storage); setups that don't meet those conditions generally fall to SAQ D. Confirm your exact route with your acquirer or assessor.
Can I keep my merchant account and stop keying in cards?
Usually, yes. The merchant account and the capture method are separate. A layer like Shuttle connects to the gateway you already use, so callers type their own card details on the keypad, or pay by IVR or link, and the payment still settles through your existing account.
Are virtual terminals safe?
The transmission itself is generally encrypted like any other online payment. The risk sits around it: the card number is spoken on your phone system, possibly recorded, visible on an agent's screen and typed on a workstation. Each of those is a place card data can leak and a system you must secure and assess. The safer designs remove those exposure points rather than hardening them.
Do call recordings matter for virtual terminal payments?
Yes, a lot. A recording that captures a spoken card number is stored cardholder data, and storing the security code after authorization is prohibited in any form. If you record calls and take cards verbally, you need pause-and-resume controls at minimum. Keypad capture avoids the problem: the recording can run throughout because the card number is never spoken.
Is a virtual terminal the same as a payment gateway?
No. The gateway is the service that processes the transaction; the virtual terminal is one interface to it, a form where a person types the card details. Most gateways offer several ways in: e-commerce APIs, payment links, and keypad capture through providers like Shuttle, alongside the virtual terminal.
What are the alternatives to my provider's virtual terminal?
The same three regardless of whose virtual terminal you are replacing: agent-assisted keypad capture, IVR self-payment, and payment links. All three keep the card number out of your systems, and none of them requires a change of merchant account in itself. If your gateway is one of the payment providers Shuttle supports, you keep it and change only how card details reach it, so your rates and settlement are unaffected.
How does a virtual terminal compare with keypad capture?
The customer experience is nearly identical and the compliance position is not. In both cases the caller is on the phone with an agent and the payment completes before the call ends. The difference is who types the card number. In a virtual terminal the agent types it, so it passes through your phone system, your agent and your workstation. With keypad capture the caller types it on their own handset and the tones route to the gateway, so it passes through none of those. That single change is what moves the payment out of your card data environment, and it is why call recording can keep running through a keypad payment, while a spoken one needs pause-and-resume controls to avoid capturing card data.
Is there such a thing as a fully PCI compliant virtual terminal?
Yes, in the sense that a virtual terminal can be operated within PCI DSS. No, in the sense that no virtual terminal removes your obligations. Because staff see and key card numbers, the surrounding systems stay in scope whichever product you pick, so compliance is something you achieve through controls around the terminal rather than something the terminal delivers for you. Approaches that keep card data out of your environment shift that balance.
What is the best virtual terminal in the UK?
If phone payments are occasional, the honest answer is usually the one already included with your merchant account, because the scope burden is manageable at low volume. If you take cards all day, the question itself is the problem. A virtual terminal where your agent keys in the number cannot take your agents, workstations and recordings out of PCI DSS scope, whichever provider builds it, because that follows from the workflow rather than from the product. At that volume the comparison worth running is agent-keyed entry against keypad capture, not one virtual terminal against another.
Related reading
PCI Compliant Phone Payments: How to Take Card Payments Over the Phone
DTMF Payment Processing: PCI Compliant Capture, Clamping & Masking
PCI Compliance Service Providers: Levels, Scope and What to Check
Still keying card numbers into a browser form? Talk to us. If you'd rather explore the technical side first, docs.shuttleglobal.com covers the flows, with sandbox accounts available for testing.