SAQ C-VT is for merchants who key card numbers in by hand, one transaction at a time, into a virtual payment terminal hosted by a compliant third party — accessed through a web browser on an isolated device. There's no local payment application and no card reader hardware involved.
Eligibility criteria — a merchant needs all of these to be true
The only payment processing happens through a virtual terminal accessed via an internet-connected web browser.
That virtual terminal is provided and hosted by a PCI DSS compliant TPSP.
The computing device used to access it is isolated to a single location and not connected to other locations or systems (firewall or network segmentation).
No software on that device causes account data to be stored — no batch processing, no store-and-forward.
No hardware is attached to that device that could capture or store account data — no card readers plugged in.
The merchant doesn't receive, transmit, or store account data electronically through any other channel.
Any retained data is paper only.
What this looks like in practice
A call-center agent or retail clerk typing a customer's card number into a payment gateway's browser-based virtual terminal on a dedicated PC, or a mail/phone-order merchant keying orders into a TPSP's virtual terminal.
Requirement scope
10 requirement categories (Requirements 1–9, 12) — notably, this is the one SAQ in the phone/counter family that skips both Requirement 10 (logging) and Requirement 11 (vulnerability scanning), reflecting how small the technical footprint really is.
ASV scanning
No — Requirement 11 doesn't apply, so no quarterly ASV scans are required.
Not a fit?
If the merchant has an actual payment application (POS software) rather than just a browser pointed at a hosted virtual terminal, that's SAQ C. If there's a card reader attached to the device or account data touches any other system, look at SAQ D.
