PCI DSS compliance for merchants is largely self-assessed using a Self-Assessment Questionnaire (SAQ). There are multiple SAQ types and choosing the wrong one either understates your compliance obligations or overstates them, both of which create problems. This guide explains each SAQ type and how to determine which one applies to your WooCommerce payment setup.
WooCommerce merchants using ConvesioPay’s hosted checkout qualify for SAQ A — the simplest SAQ, because card data never touches your server. Get started →
1. What Is a PCI SAQ?
A Self-Assessment Questionnaire (SAQ) is a validation tool for merchants who are not required to undergo a formal on-site PCI DSS assessment by a Qualified Security Assessor (QSA). The SAQ documents your compliance status with the PCI DSS requirements that apply to your specific payment environment.
You complete the SAQ annually and submit it to your acquiring bank or payment processor. Different SAQ types apply to different payment scenarios, the type that applies to you is determined by how your business handles card data.
2. SAQ A — Fully Outsourced Payments (Hosted Checkout)
Who it applies to: Merchants who have fully outsourced card data handling to a PCI DSS compliant third-party service provider. Card data is entered directly into a form or iframe hosted by the processor, it never touches your server.
Example: A WooCommerce store using ConvesioPay’s hosted payment widget. The customer enters their card details into an iframe served by Adyen; the merchant’s server never receives or stores card numbers.
Requirement count: ~22 requirements (the smallest SAQ)
Key requirements covered: Third-party oversight, access controls on your processor account, website security basics (HTTPS, no unauthorized scripts on payment pages), and staff awareness.
Annual work: 30–60 minutes to complete the questionnaire. No vulnerability scans or penetration testing required.
This is the target SAQ for most WooCommerce merchants who use a modern hosted checkout provider.
3. SAQ A-EP — Partially Outsourced (JavaScript Redirect)
Who it applies to: Ecommerce merchants who don’t directly receive card data, but whose website controls how the cardholder is directed to the payment processor. Typically: merchants using JavaScript that runs on their page and redirects to a payment form, where a compromise of the merchant’s site could affect the payment process.
Example: A checkout page that loads a JavaScript from your payment provider that intercepts the card entry and sends it to the provider’s servers, but the JavaScript itself is loaded onto your page. If your page is compromised, the script could be replaced.
Requirement count: ~191 requirements
Difference from SAQ A: Because your web application is in the payment flow (even if card data doesn’t touch your server), you’re responsible for significantly more requirements, including web application vulnerability scanning, penetration testing of the payment page, and script integrity monitoring.
SAQ A-EP applies when your website is involved in the payment redirect, even without handling card data directly. Many merchants incorrectly assess themselves as SAQ A when they should be SAQ A-EP, your payment provider can clarify which applies to your specific integration.
4. SAQ B — Imprint and Standalone Terminals
Who it applies to: Merchants using only imprint machines (carbon copy card imprinters) or standalone, dial-up terminals that are not connected to other systems or the internet.
Applies to: Physical retail. Not relevant for ecommerce-only WooCommerce merchants.
5. SAQ B-IP — Standalone IP-Connected Terminals
Who it applies to: Merchants using standalone payment terminals that connect to the processor over IP (internet) but are isolated from other business systems.
Applies to: Physical retail with IP-connected terminals. Not relevant for ecommerce-only merchants.
6. SAQ C — Payment Application Connected to Internet
Who it applies to: Merchants whose payment application (POS system) is connected to the internet but is isolated from other systems. Card data flows through your network but not through your website.
Primarily applies to: Physical retail with internet-connected POS. Not typically relevant for ecommerce-only operations.
7. SAQ C-VT — Virtual Terminal Web-Based
Who it applies to: Merchants who process transactions through a web-based virtual terminal provided by a third party. Card data is entered by staff into the terminal interface, no customers enter their own card data on your systems.
Example: A merchant who takes orders by phone and manually keys card details into a payment processor’s virtual terminal. The card data goes from the staff member’s input directly to the processor, not through a custom application or database.
8. SAQ D — All Other Merchants (Full DSS)
Who it applies to: Merchants who store, process, or transmit cardholder data in ways not covered by other SAQ types. This is the “catch-all” for complex payment environments.
Requirement count: All 12 PCI DSS requirement domains (~329 requirements)
When you’d end up here: You store card data in your own database; you’ve built a custom payment application that handles card numbers; you use a plugin that transmits card data through your web server before sending it to the processor.
SAQ D represents the full PCI DSS compliance burden. It requires an annual vulnerability scan by an Approved Scanning Vendor (ASV), a penetration test, and significantly more documentation and controls than other SAQ types.
9. Choosing the Right SAQ for WooCommerce
| Your WooCommerce setup | SAQ type |
|---|---|
| ConvesioPay hosted checkout widget (card data goes direct to Adyen) | SAQ A |
| Payment plugin that loads JavaScript on your checkout page (JS redirect approach) | SAQ A-EP |
| Payment plugin that sends card data through your WooCommerce server | SAQ D |
| Virtual terminal for phone orders only | SAQ C-VT |
If you’re unsure which SAQ applies to your setup, consult your payment processor or a Qualified Security Assessor. Using the wrong SAQ type creates compliance gaps that can result in fines or liability if a breach occurs.
For more on PCI compliance in practice, see PCI DSS Compliance Checklist: A Step-by-Step Guide for Merchants and WooCommerce PCI Compliance: Securing Your Store’s Payment Flow.
ConvesioPay’s hosted checkout qualifies WooCommerce merchants for SAQ A — the simplest compliance level. Adyen’s Level 1 certification covers the payment processing environment. Get started →