SAQ A vs SAQ B: Key PCI Compliance Differences

SAQ A vs SAQ B: Which One?

Bottom Line: SAQ A is the shortest compliance path for merchants who fully outsource card data collection to a third-party service provider, while SAQ B suits merchants with standalone payment terminals that connect directly to their processor. If you never see or touch card data because customers enter it on a payment provider’s hosted page, you’re likely SAQ A; if you have physical terminals in your store, you’re probably SAQ B.

What’s Being Compared and Why It Matters

SAQ A and SAQ B represent two of the most common self-assessment questionnaires in PCI compliance, each designed for specific payment environments with minimal card data exposure. Understanding the difference between these questionnaires determines not just which form you fill out, but fundamentally what security controls you need to implement and maintain.

The decision between SAQ A and SAQ B hinges on how your business accepts payments. SAQ A applies when you’ve completely outsourced all cardholder data functions to validated third parties. SAQ B covers merchants using standalone terminals or imprint machines with no electronic storage of card data.

This comparison becomes relevant when you’re setting up payment acceptance for the first time, changing payment processors, or when your acquirer asks you to confirm your PCI compliance status. Choosing correctly means implementing only the controls you actually need — choosing wrong means either leaving security gaps or doing unnecessary work.

Comparison Table

Aspect	SAQ A	SAQ B
Scope	E-commerce only, fully outsourced	Physical terminals, no electronic storage
Requirements	22 questions	41 questions
Typical Setup	Redirect to payment page, hosted checkout	Standalone dial-up/IP terminals
Network Requirements	None – no card data in your environment	Basic – terminals only
Quarterly Scans	Not required	Not required
Time to Complete	1-2 hours	2-4 hours
Typical Business	Small e-commerce, service businesses	Retail stores, restaurants

Detailed Breakdown

SAQ A: The Fully Outsourced Path

SAQ A applies when your business never touches card data in any form. Your customers enter their payment information directly on a validated third-party service provider’s infrastructure. Think of payment flows where clicking “pay now” redirects customers to PayPal, Stripe Checkout, or Square’s hosted payment page.

Who It’s For:

E-commerce merchants using full redirect payment pages
Service businesses taking payments via emailed invoices
Any merchant where the payment form lives entirely on someone else’s PCI-compliant infrastructure

Strengths:

Minimal compliance burden with only 22 requirements
No network security controls needed
No vulnerability scanning requirements
Fastest path to compliance for eligible merchants

Limitations:

Only applies to card-not-present environments
Requires using specific integration methods (full page redirect)
Cannot apply if you touch card data in any way, including over the phone
Your payment provider must be PCI compliant and provide their AOC

SAQ B: The Standalone Terminal Path

SAQ B covers merchants using standalone payment terminals that connect directly to the payment processor. These terminals — whether dial-up or IP-connected — process transactions independently without integrating with your other systems.

Who It’s For:

Retail stores with countertop card machines
Restaurants with wireless payment terminals
Any business using imprint machines for manual card processing
Mobile businesses using cellular-connected terminals

Strengths:

Covers most simple retail environments
No complex network segmentation required
Terminals handle all security functions independently
Works for businesses without technical IT resources

Limitations:

Cannot have any electronic cardholder data storage
Terminals must not connect to other systems (no POS integration)
Physical security requirements for terminal storage
More requirements than SAQ A (41 vs 22)

The Technical Differences That Matter

The fundamental technical distinction: data flow. With SAQ A, cardholder data never enters your environment — not through your network, not through your systems, not even momentarily. Your redirect or iframe points to the payment provider’s infrastructure where all the magic happens.

With SAQ B, cardholder data does flow through equipment you control (the terminals), but these devices operate as isolated systems. They maintain their own security functions, encryption, and direct processor connections without involving your broader IT infrastructure.

This distinction drives the requirement differences. SAQ A focuses on maintaining that separation — ensuring your systems can’t capture or redirect card data. SAQ B adds physical security requirements for the terminals themselves plus basic procedural controls around who can access and modify these devices.

Decision Framework

Choose SAQ A If:

Your only payment method is redirecting to a hosted payment page
Customers never give you card details over phone, email, or chat
You use payment links where customers enter data on the provider’s site
Your integration uses full page redirect (not just embedded forms)
You can obtain your payment provider’s current AOC

Choose SAQ B If:

You have physical payment terminals in your business
These terminals connect directly to your processor (not through your POS)
You never store, process, or transmit cardholder data electronically
Terminals are your only method of payment acceptance
You might also use manual imprinters as backup

Questions to Confirm Your Category

For SAQ A consideration:

Does your website hosting provider ever see unencrypted card numbers?
Can you access server logs that might contain card data?
Do customers ever read card numbers to you over the phone?

For SAQ B consideration:

Do your terminals connect to or share data with your POS system?
Do you batch transactions on a computer before sending to your processor?
Do you store any transaction data electronically for reconciliation?

Common Misidentification Scenarios

“We use Stripe, so we’re SAQ A” — Not if you’re using Stripe Elements or custom forms where card data touches your web server, even momentarily. That’s likely SAQ A-EP.

“We only use Square terminals, must be SAQ B” — Not if those terminals integrate with your Square POS system. Integrated terminals typically mean SAQ C or higher.

“We redirect for online but also take phone orders” — The moment you accept card data over the phone, you’ve left SAQ A territory. You’re looking at SAQ C minimum.

What Happens If You Choose Wrong

Completing the wrong SAQ creates both compliance and security risks. From a compliance perspective, your acquirer may reject your submission once they review your actual payment methods. This triggers re-assessment, potential fines, and delayed approval of your merchant account.

The security risks run deeper. If you complete SAQ A but actually handle card data via phone orders, you’ve left those interactions completely unprotected by PCI controls. A breach in this scenario means not just data loss but demonstrable non-compliance, making you liable for fraud losses and potentially losing your ability to accept cards.

How to Course-Correct

If you discover you’ve been completing the wrong SAQ:
1. Stop immediately and identify your actual payment flows
2. Complete the correct SAQ type for your current environment
3. Notify your acquirer of the change
4. Implement any missing controls before submitting

When to Get a QSA’s Opinion

Consider professional guidance when:

Your payment methods don’t clearly fit one category
You’re planning payment environment changes
Your acquirer questions your SAQ selection
You have multiple locations with different payment methods
You’re integrating new payment technologies

FAQ

Can I be eligible for both SAQ A and SAQ B?
No, you complete one SAQ type based on your highest-risk payment channel. If you have both e-commerce with redirect and standalone terminals, you’d typically complete SAQ B or higher depending on your specific setup.

What if I only process 5 transactions per year on my terminal?
Volume doesn’t determine SAQ type — payment method does. Even one transaction on a standalone terminal means SAQ B if that’s your only payment channel.

Do virtual terminals count for SAQ B?
No, virtual terminals where you key in card data on a web page are electronic processing. This scenario requires SAQ C-VT or SAQ C depending on the specific virtual terminal solution.

What’s the cost difference between SAQ A and B compliance?
Direct costs are similar — both avoid expensive scanning requirements. SAQ B adds minimal cost for physical security measures like locks for terminal storage and visitor logs.

can I use SAQ A if I use PayPal and Square?
Yes, if customers are fully redirected to these providers’ payment pages and you never handle card data yourself. Having multiple redirect-based providers doesn’t change your SAQ type.

Conclusion

The choice between SAQ A vs SAQ B ultimately comes down to a simple question: do you handle payment cards physically or electronically? SAQ A works when you’ve achieved complete separation from card data through hosted payment pages. SAQ B fits when you accept payments only through standalone terminals that don’t integrate with other systems.

Most merchants find their path forward becomes clear once they map out exactly how customers provide payment information. If you redirect online shoppers to PayPal and never touch their card data, SAQ A provides your simplest path to compliance. If you run a retail store with a dial-up terminal on the counter, SAQ B covers your needs without unnecessary complexity.

Getting this choice right sets the foundation for sustainable compliance. PCICompliance.com gives you everything you need to achieve and maintain PCI compliance — our free SAQ Wizard identifies exactly which questionnaire you need based on your specific payment methods. For merchants needing ASV scanning or ongoing compliance support, our platform handles quarterly vulnerability scans and tracks your compliance status year-round. Start with the free SAQ Wizard to confirm your correct SAQ type, or talk to our compliance team for guidance on more complex payment environments.