Dear Readers,
A virtual terminal is a web application that lets a business take a card payment without a physical card terminal. The card details are keyed into a browser form, or read by an attached reader, and the transaction is submitted to the acquirer over the merchant’s existing internet connection. It is the software equivalent of the countertop terminal, and for a business that takes occasional or remote payments it can replace one entirely.
What a virtual terminal actually is
Three things distinguish it from a payment page or a checkout:
- The merchant keys the transaction, not the cardholder. A checkout is operated by the buyer; a virtual terminal is operated by staff, usually with the cardholder on the phone.
- It runs on general-purpose hardware. Any computer, tablet or phone with a browser. There is no certified terminal to buy, deploy or replace.
- It is almost always part of an existing processing relationship. If a business already accepts cards, a virtual terminal is frequently already present in the processor’s dashboard rather than something separately purchased.
Where it fits
Virtual terminals began with mail-order and telephone-order businesses, and that is still the core case: the cardholder is not in front of you, so the card cannot be presented. Beyond that, they suit any operation where a countertop terminal is impractical or disproportionate — delivery and collection businesses taking payment before dispatch, professional services settling an invoice over the phone, remote consultants and freelancers billing between projects, and businesses with too little counter space to justify fixed hardware. They are also a sensible fallback for a merchant who normally takes payments in person but occasionally needs to take one over the phone.
What it means for risk, and why that matters technically
This is the part most feature comparisons skip. A keyed transaction is a card-not-present transaction, and it carries card-not-present economics and liability: higher interchange, no chip or contactless cryptogram to authenticate the card, and fraud exposure that sits with the merchant rather than the issuer. The card was never authenticated by the payment scheme’s own mechanisms, because it was never read.
That is the substantive difference between a virtual terminal and a chip or contactless acceptance device. A chip transaction produces a cryptogram generated by the card itself; a contactless tap does the same over the air. A keyed transaction produces neither. Address verification and card security codes reduce the exposure but they are checks on data the cardholder recites, not proof that the card exists. Where a keyed channel is genuinely needed, treat it as a deliberate risk decision and keep the volume that flows through it visible.
Where a card can be presented, presenting it is materially safer, which is the whole reason chip and contactless acceptance was deployed in the first place — see the EMV liability shift and how an EMV contact transaction actually works.
Choosing one
The questions worth asking are about the processing relationship rather than the interface: what the card-not-present rate is, whether the virtual terminal is included or billed separately, whether it supports the card-reader hardware you already own for the card-present cases, what it does about recurring billing and stored credentials, and how cardholder data is scoped for PCI DSS once staff are keying it into a browser. That last point is the one that most often surprises a small merchant.
References:-
Background reading on virtual terminals from payments industry sources:
Merchant Maverick — virtual terminals
Square — what is a virtual terminal