SAQ C is the right fit for merchants using web-based virtual payment terminals.

Short answer: SAQ C. If you’re a merchant who uses web-based virtual payment terminals and you enter card details manually, SAQ C is where your PCI DSS compliance journey typically begins. But let’s unpack that a bit more so it makes sense in real life, not just a checklist.

A quick map of the SAQ landscape

Think of the Self-Assessment Questionnaires as a ladder that lines up with how card data moves through your environment. Each rung corresponds to a set of controls tied to a specific processing setup. Here’s a simple way to picture it:

• SAQ A: This is the “fully outsourced” path. You don’t touch card data at all. A lot of merchants who rely completely on third-party processors with hosted payment pages fall here.

• SAQ B: This is for merchants who use standalone, dial-out terminals. Card data touches a small, isolated device and doesn't wander into a full-blown IT environment.

• SAQ C: This covers merchants who process card data via web-based virtual terminals where you manually type in the numbers or paste them into a secure session. The data moves through a secure payment gateway and isn’t stored in your own servers.

• SAQ D: This catch-all is for merchants who don’t neatly fit the other categories. It’s the broad, thorough path with the most requirements.

Now, why SAQ C fits the web-based virtual terminal scenario

Let’s imagine the typical flow. A customer sits on your site or in a secure browser window and you or your staff enter the card details into a virtual terminal. The merchant’s own systems don’t store the card data. Instead, the data travels straight to a payment gateway, which handles authorization and processing. The kiosk or terminal is a doorway—one that must be shielded by strong technical controls, but the data doesn’t linger in your own servers.

That’s the essence of SAQ C: the emphasis is on the protection of the entry point and the gateway, plus the surrounding infrastructure that supports safe, timely processing. The goal isn’t to police every byte that might possibly pass through a server somewhere; it’s to make sure the card data isn’t stored, isn’t exposed, and isn’t mishandled as it moves from the browser to the gateway.

A little specificity helps, too. SAQ C assumes:

• Card data enters your system via a secure, validated path through a gateway.

• You may have a website, but the critical card data interaction happens in a controlled, PCI-scope-limited environment.

• Your own servers aren’t hosting full card data, and you’ve minimized where card data may travel within your network.

What this means in practical terms

If you’re operating under SAQ C, you’ll be focusing on security controls that protect the parts of your environment that touch card data and the pathways those data take. Here are some everyday concerns you’ll see in practice:

• Network security: A solid firewall, separate networks for payment processing, and careful segmentation so card data can’t spill into the rest of your IT footprint.

• Data in transit: TLS (transport layer security) with up-to-date configurations to guard data as it zips from the terminal or browser to the gateway.

• Access controls: Only authorized staff should be able to access the systems that touch card data. That means strong passwords, MFA where possible, and regular reviews of who has access.

• Payment application security: If you’re using any software in the chain that handles card data, you want it kept current with security patches and configured in a way that minimizes exposure.

• Logging and monitoring: You’re not trying to capture every keystroke, but you are keeping meaningful logs and monitoring for unusual access patterns or anomalies.

• Vulnerability management: Regular scans, prompt remediation of discovered issues, and a process for responding to new threats.

• Third-party relationships: You’re not alone in this—your gateway provider, payment processor, and any vendor components should have their security in good shape, and you should review those relationships periodically.

Common mix-ups and how to avoid them

People sometimes assume SAQ C is a simpler path because it sounds “mid-tier.” That assumption can trip you up if your environment is a touch more complex than expected. A couple of clarifications help:

• If you ever store any card data, even temporarily, on your own systems, you’re not in SAQ C territory anymore. You’d likely need SAQ D, or a different path that fits the exact flow.

• If your web environment handles card data in any form—entered by users or clerks, pasted into a field, or briefly cached in memory—you’re operating under a scope that SAQ C covers, but only if that data truly doesn’t reside long on your servers.

• If your store only uses a hosted payment page where customers never see a card entry screen on your site, you might land in SAQ A. But if there’s a manual entry step through your own interface, SAQ C is often the right fit.

How to verify you’re on the right track (without turning this into a maze)

Think in terms of data flow. Start at the customer’s view and trace how a card number travels:

• Is the card entered on a page you host, even if the data is transmitted to a gateway immediately?

• Do you store any of that card data somewhere within your own environment?

• Do you have access to the payment gateway, and does your network stay segmented so only essential paths touch card data?

If the answers point to a gateway handling the heavy lifting and your systems not storing card data, SAQ C is typically the match. If the data touches more parts of your network or gets stored, you’ll likely look at SAQ D or a different category that aligns with the flow.

A few helpful metaphors

Here’s a simple way to picture it. Imagine card data as a letter. SAQ A is like using a courier service that never touches your house—everything happens away from your property. SAQ B and C keep the data away from your more sensitive rooms, with a single secure mailbox as the entry point. SAQ D is the full house, where many rooms could get involved and you’re keeping a detailed inventory of every space that touches the mail.

Real-life digressions that keep the idea grounded

If you’ve ever set up a new payment gateway, you know the subtle complexity of vendors. It’s not just about software; it’s about contracts, data handling promises, and the security posture of every link in the chain. You don’t want a weak link to undermine the whole chain. Think of it as assembling a team for a relay race: each leg must be trained, trusted, and tightly coordinated.

And yes, the terminology can feel a bit clinical. But the goal is straightforward: reduce the chances that card data ends up in the wrong hands. That’s a shared mission—protect customers, protect your business, and keep trust high in a digital world where payments happen in a blink.

Practical tips you can actually use

• Lock down your entry point: Ensure that your web-based terminals use strong authentication and that the session is consistently protected from the moment a customer begins entering data.

• Harden the gateway path: Work with your gateway provider to confirm that the data path is encrypted, that the gateway handles the authorization securely, and that your own systems never log full card numbers.

• Keep software current: Regular updates aren’t just bureaucratic rituals; they close doors attackers might try to slip through.

• Audit and monitor: A light-touch log of access events is enough to spot odd behavior before it becomes a problem.

• Vendor sanity checks: Periodically review third-party components and ensure they meet your security expectations. It’s worth the time to confirm that the broader ecosystem isn’t undermining your controls.

Bringing it back to the heart of the matter

If you’re working with a web-based virtual terminal and you don’t store card data, SAQ C is the right compass. It guides you toward the controls that genuinely matter for this processing model: protecting the point of entry, safeguarding the gateway, and keeping your environment lean where card data touches your world.

The path toward compliance isn’t a single gate you pass and forget. It’s a steady practice of securing the data flow, validating assumptions, and staying curious about where data travels next. When you keep that mindset, you’re not just ticking boxes—you’re building a smoother, safer payment experience for customers and a more resilient business for yourself.

If this topic sparked more questions or you want to compare it with other processing setups you’ve encountered, I’m happy to talk it through. After all, clarity about where card data goes is the best kind of confidence you can have in merchant operations.