When SAQ C applies: understanding virtual terminals that don't store cardholder data

Let me paint a quick scene: a small coffee shop takes payments with a virtual terminal. The barista types in the card data when a customer pays, but the shop itself doesn’t store any of that card information. No vault of numbers, no eternal log of PANs. Just a smooth, secure transaction that hops from the merchant’s system straight to the payment processor. If that sounds like your setup, you might be looking at SAQ C in the PCI DSS world. So, what’s SAQ C all about, and why does this scenario fit?

A quick reality check: what SAQ C really covers

SAQ C—Self-Assessment Questionnaire C for merchants—is designed for businesses that process cardholder data using payment applications but do not keep that data in their own systems. In plain terms, you’re handling card details through software that talks to a payment gateway, and you store no card data locally. It’s a very specific niche: you’re actively processing payments, but you’re not building a data storage fortress around card numbers.

Think of it this way: if your setup involves standalone, fully integrated payment terminals or a virtual terminal that connects to a gateway, and you don’t retain the card data, SAQ C is often the right fit. The gateway does the heavy lifting for data transmission and authorization, while your systems stay data-light—no sneaky pockets where CHD could linger.

Why the other options don’t quite hit the mark

• A. For merchants with no online transactions

This one sounds tempting, but it’s a trap of sorts. SAQ C is geared toward merchants who process card data electronically through payment applications and gateways. If you never process online or electronic payments at all, you’re not in the territory SAQ C covers. You’re not dealing with the same kind of data flow, and your controls would likely sit somewhere else.

• C. For merchants with a payment gateway

This sounds close, but it’s a bit of overreach. A payment gateway is a key piece, yes, but SAQ C targets those who process through a payment application and do not store CHD. If your environment involves more complex data handling, storage, or multiple data paths around the gateway, you might be in a different SAQ lane. The goal is to map the card data flow precisely, not just “have a gateway.”

• D. For all service providers irrespective of data storage

Service providers have their own, stricter routes. They’re generally not the merchant-focused SAQs at all. SAQ D for service providers or for merchants with extensive card data processing tends to look very different from SAQ C. It’s a whole different ballgame with broader requirements and a different risk profile.

Let’s dig a little deeper into why the “virtual terminal + no storage” angle matches SAQ C

• Data flow matters

If card data goes from the customer to the gateway via the virtual terminal, and then straight to the processor, your environment doesn’t “house” CHD. You’re not creating a local repository of PANs, CVVs, or track data. That keeps your risk surface smaller and your self-assessment more straightforward.

• Payment applications, not card storage

SAQ C assumes you’re using payment applications that handle card data during the transaction but do not keep it in your own system afterward. It’s about what you do with data, not just what you own. If your software app never stores CHD, you’re in the right lane.

• Practical security controls

What you’ll be thinking about with SAQ C includes access controls, strong authentication, secure transmission, proper segmentation, monitoring, and change management around those payment apps. The focus isn’t “how do I store data,” but “how do I prevent data from lingering in places it shouldn’t and how do I secure the path data travels.”

If you’re in the virtual-terminal camp, here’s how to spot the fit in your environment

• Do you enter or transmit card data directly through a payment application that connects to a gateway?

• Do you store cardholder data anywhere in your systems (even on backups or logs)?

• Are there any points where CHD could be captured or copied, outside of the gateway’s purview?

If you answer yes to the first and no to the second and third, you’re drifting toward SAQ C territory.

A few real-world nuggets that help clarify the picture

• The gateway loves to do the heavy lifting

Gateways are designed to receive card data securely, route it to the processor for authorization, and then send back a result. They’re the middleman who keeps CHD away from your systems. If you’re relying on this flow and you don’t retain data, SAQ C becomes a sensible fit.

• Virtual terminals aren’t forever stores of CHD

A virtual terminal is convenient for remote or desk-based processing. But if you don’t archive the card data after the transaction, you’re not accumulating a data treasure chest. That’s a core hallmark of SAQ C eligibility.

• “No online transactions” isn’t the sole decider

You might operate a brick-and-mortar shop or a hybrid, but if every payment is processed through a gateway with no local storage of CHD, SAQ C can still apply. The online vs. offline split matters less than the data handling pattern.

A practical path forward if you think you fit SAQ C

• Confirm your data flow in a diagram

Draw a simple map: customer → virtual terminal → gateway → processor. Note where data enters your systems and where it’s stored (or not stored). If data landings inside your systems are zero, you’re on solid ground for SAQ C.

• Audit your storage

Even if you believe you don’t store CHD, verify backups, logs, or temp files. Some systems can momentarily hold data in memory or logs. If that happens, you’re stepping into a more cautious category and might need a different SAQ or additional controls.

• Lock down access

Implement strong access controls for anyone who touches the payment apps. Multi-factor authentication, least-privilege roles, and regular access reviews go a long way toward a clean SAQ C assessment.

• Secure the transmission

Use strong encryption for data in transit between the terminal, gateway, and processor. TLS 1.2+ is standard; no hardcoding smack of old protocols. If you’re unsure, a quick pass with a security scanner can reveal gaps.

• Patch and monitor

Keep payment applications and related components updated. Establish a routine for vulnerability scanning and for monitoring unusual access attempts. It’s not glamorous, but it’s vital.

• Treat vendors wisely

Your gateway and payment app vendors matter. Choose providers with solid PCI DSS compliance statements, robust documentation, and clear incident response processes. A little vendor diligence goes a long way.

A tiny, practical checklist you can keep handy

• Data flow diagram visible to your security team

• No CHD stored on local systems or backups

• Strong access controls and MFA for payment apps

• Encrypted transmission to gateway/processor

• Regular patching and vulnerability management

• Incident response plan specific to payment data events

• Periodic review of logs and security configurations

Common myths worth debunking

• Myth: If you have a gateway, you automatically need a tougher SAQ.

Reality: It depends on how card data flows and where it’s stored. A gateway helps, but the critical question is whether CHD touches your systems at rest.

• Myth: Virtual terminals are inherently insecure.

Reality: They’re not unsafe by default. They’re secure when CHD never lands in your systems and when you enforce solid controls around the tools you use.

• Myth: SAQ C is only for online stores.

Reality: It’s about the data path more than the storefront. If your setup processes through a payment app with no CHD storage, SAQ C could be the right fit.

Where to go from here

If you’re navigating a setup that uses virtual terminals without cardholder data storage and you want to align with PCI DSS expectations, SAQ C is a sensible framework. It helps you articulate the controls you already have in place and identify gaps without overhauling everything.

For further clarity, you’ll want to consult official PCI DSS guidance and documentation from the PCI Security Standards Council. They lay out the exact requirements, the language that auditors expect, and the nuances that differentiate the various SAQ types. It’s not a mystery novel; it’s a security framework designed to keep card data secure with sensible, practical steps.

Closing thought: small steps, clear paths

Your environment matters, not the size of your business. The key is understanding where data lives and who touches it. If you’re processing through a payment application with a gateway and you don’t store CHD, SAQ C provides a clean, focused set of controls you can align with. It’s not about chasing perfection, but about keeping card data out of places it shouldn’t be and making sure the parts that do touch it are robust, monitored, and transparent.

If you’d like, I can tailor a lightweight, human-friendly overview of how your specific payment setup maps to SAQ C, with a simple diagram and a short action list. It’s all about turning a sometimes abstract standard into something you can actually apply in your day-to-day operations.