Introduction
A virtual terminal lets your team accept a card payment without ever seeing the card. Someone calls in an order, emails a signed invoice, or asks you to bill their card on file, and an employee types the numbers into a browser instead of swiping a physical card. That convenience is real—and it still leaves you fully on the hook for PCI DSS.
The PCI Security Standards Council defines a virtual payment terminal as browser access to a processor's website where the merchant manually keys in payment data. That definition matters because it draws a line: the processor secures its platform, but your people, your computers, your network, and your habits around card data are still your responsibility.
Below: how to assess your PCI scope, when SAQ C-VT fits a keyed-entry setup, how to harden the workflow, and where you can shrink exposure without slowing billing.
Key Takeaways
- PCI compliance applies whenever you store, process, or transmit card data—even through a third-party virtual terminal.
- SAQ C-VT only applies if you meet its eligibility rules; your processor’s compliance does not transfer to you.
- Never keep card numbers, security codes, screenshots, recordings, or emailed card details after a sale.
- Scope PCI across your full environment: computers, networks, integrations, call recordings, and every payment channel.
What Is a Virtual Terminal and Why Does PCI Compliance Apply?
A virtual terminal is a web-hosted payment screen. An employee logs in, types in the cardholder's name, number, expiration date, and security code, and submits the transaction. No card reader, no chip, no tap. It's built for situations where the customer and the card aren't standing in front of you.
Common US business uses include:
- Phone orders and over-the-phone deposit collection
- Invoices sent by email or mail with "call to pay" instructions
- Remote payment collection for service calls or job completions
- Professional-service retainers and consultation fees
- Contractor deposits and final payments collected off-site
- B2B orders placed by phone, fax, or purchase order
The Transaction Flow (and Where Risk Lives)
The basic path looks simple: collect the card details, key them into the terminal, get an authorization, and let the funds settle. A gateway and merchant account typically sit behind that browser screen, invisible to the employee doing the typing.
Here's the part that gets missed: the payment process starts the moment your business receives the card details, not when the data reaches the processor. If an employee writes the number on a sticky note while the customer is talking, that's already a PCI event, whether or not the transaction ever gets keyed in.
There's also a real difference between a PCI-compliant service provider and a PCI-compliant merchant environment. Your processor being validated doesn't validate your office, your staff training, or your handling procedures.
That gap matters more with virtual terminals. These transactions are card-not-present by nature, so you face added exposure to fraud, chargebacks, and social engineering. There's no chip or signature to confirm who's on the other end of the call.
Who May Qualify for SAQ C-VT?
SAQ C-VT is a PCI DSS Self-Assessment Questionnaire for merchants that manually key card data into an internet-connected, third-party virtual terminal, with no other card-data channels running in the background.
The official version, published by PCI SSC, is the only document that should determine eligibility. PCI SSC updated its SAQ set for PCI DSS v4.0.1 with clarified criteria, so confirm you're working from the current version before you assume anything applies to you.
Core eligibility conditions to check:
- The virtual terminal is hosted by a PCI DSS-compliant third-party provider
- Card data is entered manually, one transaction at a time, through a browser (not via connected readers or batch uploads)
- The computer used is isolated from other business systems and never stores cardholder data electronically
- No other electronic channel receives, transmits, or stores card data in a way that would widen your PCI scope
SAQ C-VT probably won't fit if you have:
- An ecommerce checkout running alongside the virtual terminal
- A connected point-of-sale system sharing the same network
- Custom payment software or API integrations
- CRM or accounting system integrations that touch card data
- Recurring billing that stores card details
- Multiple linked devices or locations sharing the terminal setup
Your acquirer, a card brand, or a qualified PCI advisor can require a different questionnaire even if you think you qualify. Confirm the correct SAQ before signing an Attestation of Compliance. Choosing the wrong form can delay validation and create extra remediation work later.
What PCI Controls Should a Virtual-Terminal Merchant Implement?
Meeting SAQ C-VT eligibility is step one. Actually implementing the controls is where compliance lives day to day.
Device, Access, and Network Basics
- Keep the operating system and browser current with security patches
- Enable anti-malware protection on the payment device
- Restrict that computer to authorized payment activity only, no general web browsing
- Assign unique user IDs and strong passwords; never share login credentials
- Use multi-factor authentication where it's supported
- Remove access immediately when an employee leaves or changes roles
- Secure Wi-Fi and firewall settings, and isolate the payment workstation from unrelated systems on your network
Card-Data Handling Rules for Staff
- Never write down, photograph, screenshot, or paste card numbers into another app
- Never retain the card security code after authorization, in any form
- Never ask a customer to leave card details in a voicemail or text
- Destroy any permitted paper records per your documented retention policy
That security code rule isn't optional or negotiable. PCI SSC's guidance is explicit that storing sensitive authentication data after authorization is prohibited, even in a digital audio recording, and even if it's encrypted.
That's a real gap for phone-based businesses: a recorded call where a customer reads out their CVV becomes stored prohibited data unless you've built in a way to redact it or pause the recording.
Screen recordings, clipboard tools, CRM notes fields, and help-desk tickets create the same kind of unintentional exposure. If an agent pastes a card number into a customer record "just to double-check it later," that field is now part of your cardholder data environment.
Operational Controls to Keep in Place
- Written procedures and regular employee training
- Periodic access reviews and prompt offboarding
- An incident-response plan employees actually know about
- Retained evidence: policies, training logs, device inventories, and your provider's compliance documentation
How to Create a PCI-Compliant Virtual-Terminal Workflow
Start by mapping the entire payment journey, not just the moment of the transaction. Trace it from the initial phone call or invoice response through authorization, receipt delivery, settlement, refunds, and any chargeback that follows. Note every person, device, application, and record touched along the way.
From there, build the actual workflow:
- Write a standard transaction script that verifies the customer, limits how much card detail gets spoken aloud, and tells staff what to say if a payment gets declined.
- Lock down a dedicated device or workstation for payment entry only. No unapproved software, limited physical access, and a documented list of who's allowed to use it.
- Test for accidental data capture by reviewing call recordings, screen captures, print queues, browser history, clipboard tools, and CRM fields.
- Set a recurring review schedule covering software updates, access lists, vendor documentation, retraining, and any changes to how you accept payments.
Keep that workflow narrow on purpose. A business running one isolated virtual-terminal computer sits in a different PCI scope than one where staff share workstations, an invoicing tool auto-fills stored card tokens, or three locations all log into the same terminal account.
Each of those additions can push you out of SAQ C-VT eligibility entirely. Most merchants don't realize it happened until an acquirer flags it.
Can a Business Reduce PCI Scope When Using a Virtual Terminal?
Reducing PCI scope means limiting where card data can enter, move, or sit. Scope reduction is a design choice that still leaves the applicable requirements in place.
The most common comparison is employee-keyed entry versus letting the customer type their own card details into a hosted payment page, payment link, or secure IVR system.
| Method | Who enters the data | Typical scope consideration |
|---|---|---|
| Employee-keyed virtual terminal | Staff member | Must meet SAQ C-VT's full eligibility test; isolated device required |
| Hosted payment page or link | Customer | May align with SAQ A if your systems never touch the data, but this depends entirely on the outsourcing setup |
| Customer-entered phone/IVR payment | Customer, via automated system | Depends on whether card data ever reaches an agent, recording, or connected system |
None of these labels are automatic. Tokenization, encryption, or a vendor calling itself "PCI compliant" doesn't by itself determine which SAQ applies to you. The full implementation, including what the provider actually secures versus what you secure, is what decides your scope.
Before switching approaches, weigh the trade-offs:
- Customer experience and drop-off rates on a self-service page
- How refunds and recurring billing get handled
- Accessibility for customers less comfortable with self-checkout
- Existing integrations with your CRM or accounting tools
- Call center workflows that depend on agent-assisted payment
If you're not sure which setup fits your business, Clearwater Processing's PCI compliance solutions can help review your current payment environment. You get a processing setup matched to how you operate, with clarity on what stays your responsibility either way.
How to Choose a Virtual-Terminal Provider and Validate Your Setup
Provider support and compliance posture vary widely. Before you sign, run this checklist:
- PCI DSS validation status and a current Attestation of Compliance (AOC)
- Compatibility with your merchant account and gateway
- User-access controls with MFA and role-based permissions
- Transaction logs and reporting you can export for audits
- Tokenization options if you store cards for recurring billing, plus automatic updating of stored cards that are about to expire
- Clear refund workflow and reachable support hours
- Data-retention practices and a written shared-responsibility matrix
Ask the provider directly:
- Which systems are actually in PCI scope on their end?
- What am I responsible for securing on my end?
- Which SAQ typically applies to merchants using this exact setup?
- How do changes to my integrations affect my compliance status?
Their AOC covers their platform only. Yours still has to cover your policies, training records, device controls, and evidence—one does not replace the other.
A quick decision framework:
- Occasional remote payments → a simple virtual terminal usually fits
- Frequent employee-keyed payments → isolated device and strict access controls
- Recurring billing → confirm tokenization and storage rules first
- Multiple users or locations → scope often expands past basic SAQ C-VT
- Integrated accounting or CRM → map card-data flow before you connect
Next step: inventory your workflow, pull your provider’s compliance docs, list every system that touches card data, and confirm the right validation path with your acquirer or a qualified PCI professional.
How Clearwater Processing Supports PCI-Compliant Virtual Terminals
When you want help applying the framework above, Clearwater Processing has built tailored payment environments since 2003, including virtual terminal access, PCI compliance support with $100,000 breach protection insurance, merchant reporting, and 24/7/365 US-based backend support for businesses across 32 states. Each client also gets their representative’s personal cell number, so a refund or access question doesn’t wait in a queue. Your dedicated representative is a single point of contact for questions about keyed payments and PCI scope.
No provider—including Clearwater—can guarantee your compliance status. The value is having someone walk the setup, scope, and validation path with you.
Frequently Asked Questions
Do I really need PCI compliance?
Yes. Any merchant that stores, processes, or transmits payment card data has PCI DSS responsibilities, even through a third-party virtual terminal. The exact validation method depends on your specific payment environment.
Is there a free way to get certified in PCI DSS?
No. There's no free route to a formal certification. The PCI Security Standards Council (PCI SSC) provides free self-assessment questionnaires, but these aren't the same as a formal certification. Use official PCI SSC materials and confirm which validation path your acquirer requires.
What does PCI DSS stand for?
Payment Card Industry Data Security Standard. It sets baseline security requirements for protecting cardholder data across any business that handles card payments.
What is the latest version of PCI DSS?
PCI SSC released v4.0.1 in mid-2024, retiring the earlier v4.0 version by the end of that year. Confirm the current version and effective dates with the PCI Security Standards Council before you rely on any compliance claim.
Does using a virtual terminal make my business PCI compliant?
No. A compliant virtual terminal provider covers only its own platform. You're still responsible for securing your devices, users, network, policies, and how staff handle card data.
What is SAQ C-VT, and who should complete it?
SAQ C-VT is for merchants that manually key card data into an eligible third-party virtual terminal under specific isolation conditions. If you use other payment channels or integrations, a different SAQ likely applies instead.
