How Virtual Terminal Works
A virtual terminal turns any internet-connected device — laptop, tablet, or desktop — into a payment acceptance point. Instead of swiping or dipping a physical card, a merchant or agent types the card details directly into a secure, browser-based form provided by their payment processor. The processor then routes the authorisation request through the card network in exactly the same way a physical POS terminal would.
Merchant logs in
Card details are entered
Fraud checks run automatically
Authorisation is returned
Settlement
Why Virtual Terminal Matters
Virtual terminals unlock card acceptance for a wide range of businesses that cannot rely on a physical card reader or an e-commerce checkout flow. They are the backbone of telephone order centres, field service companies, nonprofits taking donations by phone, and B2B businesses that invoice clients and collect payment verbally.
According to Nilson Report data, MOTO transactions — the primary use case for virtual terminals — accounted for roughly 10% of all card transaction volume in North America in 2024, representing hundreds of billions of dollars in annual payment value. A separate study by the Merchant Risk Council found that 34% of merchants surveyed rely on a virtual terminal as their primary or secondary payment acceptance method, underscoring how common the tool remains even in an era of tap-to-pay and digital wallets.
MOTO defined
Virtual Terminal vs. Point of Sale
Both a virtual terminal and a point-of-sale system allow a merchant to accept card payments, but they serve different environments, carry different costs, and have different fraud and chargeback profiles.
| Feature | Virtual Terminal | Point of Sale (POS) |
|---|---|---|
| Hardware required | None — browser only | Card reader, terminal, or POS device |
| Card presence | Not present (CNP) | Present (chip, tap, swipe) |
| Interchange rate | Higher (CNP premium) | Lower (card-present rate) |
| Chargeback risk | Higher | Lower |
| Fraud tools | AVS, CVV, fraud scoring | EMV chip, PIN, contactless |
| Best for | Phone orders, invoicing, field service | Retail, restaurants, in-store |
| Setup time | Minutes (web access only) | Hours to days (hardware + software) |
| PCI scope | Reduced (processor handles data) | Varies by integration type |
The core trade-off is convenience versus cost. A virtual terminal removes all hardware dependency and can be operational in minutes, but the merchant pays a higher per-transaction rate and assumes more chargeback liability.
Types of Virtual Terminal
Virtual terminals are not monolithic — they vary in feature depth and intended use case. Understanding the variants helps merchants choose the right tier for their volume and workflow.
Basic virtual terminal: A simple keyed-entry form for one-off transactions. Suitable for low-volume merchants or occasional phone orders. Minimal reporting, no card-on-file.
Full-featured virtual terminal: Includes transaction history, refund processing, void capability, receipt generation, and basic reporting. Most mid-market processors offer this as the default tier.
Virtual terminal with card-on-file / tokenisation: Allows the merchant to save a card token after the first manual entry and charge it again without re-keying. Critical for repeat customers and subscription businesses that handle some orders by phone.
Virtual terminal with recurring billing: Extends tokenisation with a built-in scheduler. The merchant keys in the card once and configures a billing frequency; the system charges automatically. Blurs the line between a virtual terminal and a full subscription management platform.
Multi-user / role-based virtual terminal: Designed for call centres or teams. Supports multiple agent logins, permission levels, and per-agent transaction reporting. Often includes call recording integration for MOTO compliance.
Best Practices
A virtual terminal is a powerful tool, but its manual nature introduces operational and security risks that merchants must actively manage.
For Merchants
Obtain explicit verbal or written authorisation before charging. For telephone orders, many processors require you to record or document that the cardholder consented. Keep this record for at least 18 months to defend against chargebacks.
Never write down or store raw card numbers. If a customer reads their card number to you, key it directly into the terminal. Do not write it on paper, paste it into a chat tool, or store it in a spreadsheet. Raw PANs outside a PCI-compliant environment create serious compliance exposure.
Always run AVS and CVV checks. Decline or escalate transactions where both checks fail. A mismatch on billing address or CVV is a strong fraud signal for keyed transactions.
Set transaction velocity limits. Configure your processor to alert or block if a single card is charged multiple times within a short window — a common pattern in card testing attacks.
Reconcile daily. Compare your virtual terminal transaction log against your bank settlement report every business day. Discrepancies caught early are far easier to resolve.
For Developers
Use the processor's hosted virtual terminal rather than building your own keyed-entry form. Building a custom form puts raw card data in scope for your servers and dramatically expands PCI DSS compliance requirements.
Integrate via API for anything beyond one-off charges. If the business needs recurring billing or card-on-file, use the payment gateway API with tokenisation rather than having agents key in cards repeatedly.
Log transaction IDs, not card data. Store the processor-issued transaction reference and token. Never log PANs, CVVs, or full expiry dates in application logs.
Test in sandbox with realistic MOTO scenarios. Most processors provide test card numbers that simulate AVS mismatches, CVV failures, and soft declines. Cover these cases before going live.
Common Mistakes
Storing card data outside the terminal. Copying card numbers into CRM notes, email threads, or spreadsheets is one of the most common PCI violations among small merchants using virtual terminals. The processor's system is the only place card data should live.
Ignoring AVS/CVV decline signals. Some merchants override failed fraud checks to avoid losing a sale. This dramatically increases chargeback rates. A single large chargeback can cost more than dozens of declined transactions.
Using a shared login for all staff. Multi-agent businesses that share a single virtual terminal login lose the ability to trace fraudulent or erroneous transactions to a specific agent. Use role-based access with individual credentials.
Failing to issue receipts. Card networks require merchants to provide transaction receipts for MOTO sales. Failing to do so weakens your position in a chargeback dispute where the cardholder claims they never authorised the charge.
Treating the virtual terminal as a substitute for a proper e-commerce checkout. For online sales where customers can self-serve, a hosted checkout or embedded payment form is faster, cheaper (lower CNP rate), and more scalable. A virtual terminal is for human-mediated transactions, not self-service web purchases.
Virtual Terminal and Tagada
Tagada's payment orchestration layer sits between merchants and their processors, giving teams a single integration point that can route virtual terminal transactions — alongside online, in-app, and in-person payments — through whichever processor offers the best rate, approval rate, or redundancy for a given transaction.
For MOTO-heavy businesses, Tagada's routing logic can automatically direct keyed transactions to the processor with the lowest CNP rate in your portfolio, reducing the cost premium that virtual terminal transactions typically carry without any manual intervention from your team.