PCI DSS Levels and SAQ Types

Most SaaS companies using modern payment processors can qualify for the simplest SAQ type (SAQ A), reducing compliance burden by roughly 90% compared to the full standard. This guide explains the levels, SAQ types, and how to determine which applies to you.

Key Takeaways

Point	Summary
Merchant Levels	Four levels based on annual transaction volume (Level 1 = most transactions)
Service Provider Levels	Two levels based on transaction volume
SAQ Types	Nine different questionnaire types based on payment integration method
SAQ A	Simplest option (~27 questions in v4.0), for fully outsourced card handling
Level 1	Requires on-site QSA assessment, not just SAQ
Key determinant	How you integrate payments matters more than company size

Merchant Compliance Levels

Card brands define four compliance levels for merchants based on annual Visa transaction volume (Mastercard and others have similar thresholds):

Level	Annual Visa Transactions	Validation Requirements
Level 1	Over 6 million	Annual on-site QSA assessment, quarterly ASV scans
Level 2	1 to 6 million	Annual SAQ by ISA or QSA, quarterly ASV scans
Level 3	20,000 to 1 million (e-commerce only)	Annual SAQ, quarterly ASV scans
Level 4	Under 20,000 (e-commerce) or under 1 million (all other)	Annual SAQ, quarterly ASV scans recommended

Note: Different card brands have slightly different thresholds:

• Mastercard: Uses 6 million, 1 million, and 20,000 thresholds
• American Express: Uses 2.5 million, 50,000, and 10,000 thresholds
• Discover: Generally follows Visa thresholds

Escalation: If you experience a data breach, you may be escalated to Level 1 regardless of transaction volume.

Service Provider Compliance Levels

Service providers (payment processors, hosting providers, etc.) have stricter requirements:

Level	Annual Transactions	Validation Requirements
Level 1	Over 300,000	Annual on-site QSA assessment, quarterly ASV scans
Level 2	Under 300,000	Annual SAQ-D (Service Provider), quarterly ASV scans

Key distinction: Even at Level 2, service providers must complete the full SAQ-D, which covers all PCI DSS requirements.

Understanding SAQ Types

The Self-Assessment Questionnaire you complete depends on how you handle card data, not just your transaction volume:

SAQ A: Fully Outsourced E-commerce

Questions: ~27 in v4.0 (the minimum)
Best for: E-commerce using hosted payment pages, iframes, or redirects

You qualify if:

• All payment processing is entirely outsourced to PCI-compliant providers
• Your website doesn't receive cardholder data (card numbers never touch your servers)
• You use only iframe or redirect payment forms
• You have no electronic cardholder data storage

Common implementations:

• Stripe Checkout (hosted payment page)
• Stripe Elements (iframe)
• Adyen Web Components (iframe)
• PayPal hosted buttons
• Shopify Payments (built-in)

What you attest to:

• Maintaining secure systems
• Using only compliant service providers
• Proper implementation of hosted payment forms
• Physical security of payment devices (if any)

SAQ A-EP: E-commerce with Website Integration

Questions: ~191 in v4.0
Best for: E-commerce where your website controls payment page elements but doesn't receive card data

You qualify if:

• Your website hosts the payment page (not redirected to third party)
• You use JavaScript libraries that send card data directly to the processor
• Your website never receives, processes, or stores cardholder data
• Card data goes directly from customer browser to payment processor

Important: SAQ A-EP applies when your web server serves the page containing the payment form, even if JavaScript sends data directly to the processor. This is a common area of confusion.

Common implementations:

• Custom checkout pages with Stripe.js
• Braintree Hosted Fields on your domain
• Custom-designed payment forms using tokenization APIs

Key difference from SAQ A: Your server serves the page, so you need controls over web server security, vulnerability management, and change control.

SAQ B: Imprint or Dial-Out Terminals Only

Questions: ~43 in v4.0
Best for: Brick-and-mortar using standalone payment terminals

You qualify if:

• You use only imprint machines or standalone dial-out terminals
• Terminals connect via phone line (not internet)
• No electronic cardholder data storage

Typical scenario: Physical stores with traditional credit card terminals that dial out over phone lines.

SAQ B-IP: Standalone IP-Connected Terminals

Questions: ~89 in v4.0
Best for: Standalone terminals connected via IP

You qualify if:

• You use only PTS-approved standalone payment terminals
• Terminals connect to payment processor via IP
• No electronic cardholder data storage
• Terminals are not connected to other systems in your environment

Typical scenario: Physical stores with modern IP-connected terminals that are isolated from other systems.

SAQ C-VT: Virtual Payment Terminals

Questions: ~87 in v4.0
Best for: Key-entered transactions via virtual terminal

You qualify if:

• You manually enter card data via a web-based virtual terminal
• Virtual terminal is provided by PCI-compliant third party
• One transaction at a time (no batch processing)
• Computer used is isolated and secured

Typical scenario: Phone orders entered manually into a web-based payment terminal.

SAQ C: Payment Application Systems

Questions: ~172 in v4.0
Best for: Payment terminals connected to the internet and your network

You qualify if:

• You have payment application systems connected to the internet
• No cardholder data storage
• Payment application is segmented from other systems

Typical scenario: Point-of-sale systems connected to your network and the internet.

SAQ P2PE-HW: Point-to-Point Encryption (Hardware)

Questions: ~33 in v4.0
Best for: Merchants using validated P2PE hardware solutions

You qualify if:

• You use only PCI-listed validated P2PE solution
• No access to decrypted cardholder data
• P2PE solution provider handles all decryption

Benefit: P2PE significantly reduces scope because encrypted data at the point of interaction cannot be decrypted in your environment.

SAQ D (Merchant): All Other Merchants

Questions: 330+ in v4.0 (all requirements)
Applies when: You don't qualify for any other SAQ type

You must use SAQ D if:

• You store cardholder data electronically
• You don't meet the criteria for simpler SAQ types
• You have a complex payment environment

Typical scenario: Merchants with custom payment applications, stored card data, or complex integrations.

SAQ D (Service Provider): All Service Providers

Questions: 330+ in v4.0 (all requirements)
Applies to: All service providers at Level 2

Service providers don't have simplified SAQ options. Level 2 service providers complete SAQ D; Level 1 service providers require full QSA assessments.

SAQ Selection Decision Tree

Follow this process to identify your SAQ type:

Step 1: Are You a Merchant or Service Provider?

Service Provider: You provide services to other merchants or processors that involve cardholder data. Go to SAQ D (Service Provider) or Level 1 QSA assessment.

Merchant: You accept payments for goods or services. Continue to Step 2.

Step 2: Do You Store Cardholder Data Electronically?

Yes: SAQ D (Merchant)
No: Continue to Step 3

Step 3: How Do You Accept Card Payments?

Only imprint machines or dial-out terminals: SAQ B
Only standalone IP-connected terminals: SAQ B-IP
Only virtual terminal (key-entered, web-based): SAQ C-VT
Payment terminals connected to internet/network: SAQ C
E-commerce (online payments): Continue to Step 4

Step 4: How Is Your E-commerce Payment Page Implemented?

Redirect to hosted payment page OR iframe from payment provider:

• Your server never receives card data
• Your website doesn't control payment form elements
• Result: SAQ A

Your website serves the payment page with JavaScript tokenization:

• Card data goes directly from browser to processor
• Your server serves the page but doesn't receive card data
• Result: SAQ A-EP

Your website receives card data:

• Card numbers pass through your server
• Result: SAQ D (Merchant)

Common Implementation Patterns

Stripe Implementations

Integration Type	SAQ Type	Notes
Stripe Checkout	SAQ A	Fully hosted, redirects to Stripe
Stripe Payment Links	SAQ A	Fully hosted on Stripe
Stripe Elements	SAQ A	Iframe tokenization
Stripe.js with custom form	SAQ A-EP	Your page, direct tokenization
Server-side card handling	SAQ D	Card data touches your server

Adyen Implementations

Integration Type	SAQ Type	Notes
Pay by Link	SAQ A	Fully hosted
Drop-in	SAQ A	Iframe components
Web Components	SAQ A	Iframe tokenization
Custom integration with API	SAQ A-EP or D	Depends on implementation

Common Mistakes

Mistake 1: Assuming Stripe.js automatically means SAQ A
Reality: If your server serves the checkout page (even with client-side tokenization), you're likely SAQ A-EP.

Mistake 2: Thinking SAQ A means no compliance work
Reality: SAQ A still has ~27 questions (in v4.0) including service provider management, physical security, and policy requirements.

Mistake 3: Ignoring scope expansion from connected systems
Reality: Systems connected to payment processing may increase your scope even if they don't directly handle card data.

Quarterly ASV Scans

Regardless of SAQ type, if you have internet-facing systems, you likely need quarterly Approved Scanning Vendor (ASV) scans.

Who needs ASV scans:

• Level 1, 2, and 3 merchants (required)
• Level 4 merchants (recommended)
• All service providers (required)

What ASV scans check:

• External vulnerabilities
• Known security issues
• Compliance with PCI scanning requirements

Passing requirements:

• No critical or high-severity vulnerabilities
• No failing checks for PCI-specific requirements
• Quarterly scans with passing results

Moving Between SAQ Types

As your business evolves, you may need to move to a different SAQ:

Upgrading (More Complex SAQ)

When this happens:

• You add new payment channels
• You start storing card data
• Your implementation changes
• Transaction volume increases to Level 1

Action required:

• Complete new SAQ or QSA assessment
• Implement additional controls
• Update documentation

Downgrading (Simpler SAQ)

When this happens:

• You migrate to fully hosted payment forms
• You implement tokenization to eliminate card storage
• You simplify your payment architecture

Action required:

• Document the architecture change
• Complete new SAQ type
• Remove unnecessary controls (optional, but reduces maintenance)

Frequently Asked Questions

My acquiring bank says I'm Level 4. Do I still need to complete an SAQ?

Technically, SAQ completion is recommended but not always enforced for Level 4 merchants. However, your acquiring bank may require it, and it's good practice. If there's a breach, lack of validated compliance increases your liability.

Can I complete an SAQ myself, or do I need a QSA?

For Levels 2-4, you can self-assess using the appropriate SAQ. However, complex environments benefit from professional guidance. Level 1 merchants and Level 1 service providers must use a QSA.

How often do I need to revalidate?

SAQ completion and ASV scans (if required) must be done annually at minimum. Some acquiring banks require quarterly SAQ updates for higher-risk merchants.

What if I use multiple payment methods?

Complete the applicable SAQ for each distinct payment channel, or use SAQ D to consolidate all channels into a single assessment. For example, if you have both in-store terminals and e-commerce, you may need to complete both SAQ B and SAQ A separately, or use SAQ D which covers all scenarios. Consult with your acquiring bank or QSA for guidance on your specific situation.

---

Not sure which SAQ applies to your payment setup? Talk to our team

---

Sources

• PCI SSC SAQ Instructions and Guidelines - Official SAQ documentation
• Visa Merchant Levels - Visa compliance requirements
• Mastercard SDP Program - Mastercard requirements