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 agent's line carries flat tones or silence, 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 | No (captures card data) | 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. 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 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; payment links cover the rest. Nothing about your acquiring relationship has to change for the card data to stop passing through your staff.
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 and payment plans run against the stored token rather than another round of card entry.
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 (wired into your phone system or desktop) and the caller types their card number on their 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.
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.