Virtual Terminal

Also called VT, web terminal, keyed entry portal

A web page where you type in a card number to charge it. Useful, expensive per transaction, and a fraud magnet if left unlocked.

What it is

A virtual terminal is a browser-based screen where a staff member manually keys a card number, expiration and CVV to charge a customer. It's how phone orders, mail orders, deposits taken over the phone and one-off invoices get processed without any physical hardware. Nearly every gateway includes one, and most processors provide one as standard. Because the card isn't physically present and hasn't been dipped or tapped, virtual terminal transactions price as card-not-present — significantly more expensive than card-present. PayPal prices its virtual terminal well above its card-present rate, and Square prices manual entry above in-person. Both publish current figures on their own fee pages. That gap of roughly 90 to 110 basis points is the cost of not having the card. The modern alternative for most virtual terminal use cases is a payment link or a text-to-pay request: instead of your staff typing the customer's card, you send them a secure link and they enter it themselves. That's cheaper on fraud exposure, better on PCI scope, and often qualifies for better interchange because 3-D Secure can run.

Why it matters to your business

Keyed transactions cost you roughly 90 to 110 basis points more than card-present. If a meaningful share of your volume is keyed, moving even half of it to payment links or text-to-pay is a direct margin gain — and it usually improves your fraud posture at the same time. The security exposure is the bigger risk. A virtual terminal with a shared login and unrestricted refund rights is the most common internal fraud vector in small business payments, and it's fixable in one afternoon with individual logins and permission settings.

Where it gets contested

Virtual terminals are the most commonly abused tool in a small business's payment stack, and the abuse is usually internal or social-engineering, not sophisticated. An unlocked virtual terminal on a shared browser login is a standing invitation: staff can run cards, refunds can be issued to unrelated cards, and card-testing attackers who get credentials can run thousands of small authorizations. The second problem is PCI scope. Writing card numbers on a notepad to key in later, or emailing them, is extraordinarily common and is a flat violation. Many businesses that would never store a card in a database keep a stack of paper by the register. The honest counterpoint: for a service business taking deposits over the phone, or a B2B seller collecting from an AP department that will only read a card aloud, the virtual terminal is the tool that works. It shouldn't be eliminated. It should be locked down — individual user logins, refund permissions restricted to owners, velocity limits set, and payment links used wherever the customer can be reached digitally.

How to check it yourself

Log into your virtual terminal and check three things: does every employee have their own login, is refund permission restricted to specific users, and are there velocity or amount limits set? If everyone shares one password, fix that today. Then check what percentage of last month's volume was keyed.

Receipts

Claims above that are checkable, with where to check them. Published so you do not have to take anyone's word for it.

PayPal prices its virtual terminal above its card-present rate of 2.29% + $0.09, with keyed at 3.49% + $0.09
paypal.com ↗
Square prices manual entry / card on file at 3.5% + 15¢ against 2.6% + 15¢ for in-person tap/dip/swipe
squareup.com ↗
Gateways include virtual terminal, text-to-pay, hosted payment links and QR alongside the customer vault
nmi.com ↗