The short answer: If your e-commerce site redirects customers to a third-party payment page (like PayPal or Stripe Checkout) and never touches card data, you likely qualify for SAQ A (the shortest questionnaire with only 22 questions). If your site hosts a payment form but uses JavaScript to send card data directly to your payment processor without it touching your server, you need SAQ A-EP (193 questions, significantly more complex). The distinction hinges on whether cardholder data flows through systems you control.
This matters more than ever in September 2026. With WordPress adding automated plugin security reviews and threat actors exploiting everything from LiteSpeed Enterprise flaws for root access on shared hosting to Cisco Secure Email Gateway zero-days, understanding your PCI scope isn't just about compliance—it's about knowing what systems attackers can leverage to reach payment data.
What is SAQ A and who qualifies?
SAQ A is designed for card-not-present merchants who have fully outsourced all cardholder data functions. Your business qualifies if:
- Your website redirects customers to a third-party payment page (Stripe Checkout, PayPal, Square hosted pages)
- Cardholder data never enters your website, systems, or network
- You don't store, process, or transmit card data in any form
- The payment page is entirely on the processor's domain
Real-world example: A customer clicks "Pay Now" on your site, lands on checkout.stripe.com, enters their card details there, and returns to your site after payment completes. Your server never saw the card number.
With only 22 questions covering basic security hygiene—keeping systems patched, using strong passwords, maintaining firewall configurations—SAQ A is the simplest path. But many merchants who think they qualify actually don't.
What is SAQ A-EP and when does it apply?
SAQ A-EP covers e-commerce merchants using direct post or JavaScript solutions where payment forms appear on your website but card data bypasses your server. You need SAQ A-EP if:
- Payment forms are embedded on your domain using iframes or JavaScript libraries
- Card data is captured in your customer's browser and sent directly to the payment processor
- Your website controls the payment page look, feel, and user experience
- Examples: Stripe.js, Braintree.js, Authorize.net Accept.js implementations
The critical difference: Even though your server never processes the card data, your website's code and hosting environment are in scope because vulnerabilities there could intercept payment information before it reaches the processor.
SAQ A-EP requires 193 questions covering network segmentation, vulnerability scanning, penetration testing, file integrity monitoring, and comprehensive security policies. It's exponentially more complex than SAQ A.
Why the distinction matters for security
The September 2026 threat landscape demonstrates why PCI scoping isn't academic. Consider the LiteSpeed Enterprise vulnerability that allows low-privilege website users to gain root access on shared hosting servers. If you're on shared hosting with an SAQ A-EP implementation, an attacker exploiting this flaw could potentially inject malicious JavaScript into your payment forms to steal card data before it reaches your processor.
Similarly, the Telegram Desktop flaw that plants hidden JavaScript in exported HTML files illustrates how easily client-side code can be weaponized. SAQ A-EP merchants must defend against these exact attack vectors.
With hackers targeting exposed Vite dev servers to steal AWS and Azure secrets, the attack surface extends beyond your payment page to your entire development and deployment pipeline.
Common mistakes that force you into the wrong SAQ
Mistake 1: Logging full URLs that contain card data. If your analytics or server logs capture GET parameters or POST bodies that briefly contained card data, you've processed cardholder data—even if you immediately discard it. This disqualifies you from SAQ A.
Mistake 2: Storing transaction receipts with full card numbers. Keeping "thank you" page content or email templates that include unmasked PANs (primary account numbers) means you're storing cardholder data.
Mistake 3: Using payment plugins that cache card data. Some e-commerce plugins temporarily write card details to local storage, session variables, or database tables "for processing." This immediately triggers SAQ D requirements (the most stringent level).
Mistake 4: Mixing payment and non-payment systems. If your payment form JavaScript shares a server with your blog, customer portal, or other applications, your entire environment comes into scope for SAQ A-EP—including that outdated WordPress installation.
Mistake 5: Assuming your processor handles everything. Even with tokenization, if the initial card capture happens on your infrastructure, you own that risk moment.
Step-by-step: Determining your correct SAQ
Step 1: Map your payment flow. Diagram exactly where card data is entered, how it travels, what systems touch it, and where it's stored. Use browser developer tools to watch network requests during test transactions.
Step 2: Check your domain. During payment, does the browser URL bar show your domain or your processor's domain? If it's your domain (even with an iframe from the processor), you're likely SAQ A-EP territory.
Step 3: Review your code. Search your codebase for any handling of card-related form fields. Even validation logic that touches card numbers before sending them to the processor expands your scope.
Step 4: Audit your logs and databases. Run searches for test card numbers (like 4111111111111111) across all logs, databases, backups, and monitoring systems to confirm nothing is captured.
Step 5: Consult your payment processor. Most processors provide explicit SAQ guidance for their integration methods. Stripe, for example, clearly documents which integration patterns qualify for SAQ A vs. SAQ A-EP.
Step 6: Consider a professional assessment. QSAs (Qualified Security Assessors) and penetration testing firms can definitively scope your environment, especially for edge cases.
What SAQ A-EP compliance actually requires
If you land in SAQ A-EP, expect these requirements:
- Quarterly vulnerability scans by an Approved Scanning Vendor (ASV)
- Annual penetration testing of your web application and network
- Network segmentation documentation proving your cardholder data environment (CDE) is isolated
- Web application firewall (WAF) protecting payment pages
- File integrity monitoring to detect unauthorized changes to payment code
- Security awareness training for all personnel with system access
- Incident response plan specifically covering payment data breaches
- Vendor management documentation for any third parties with system access
Timeline: First-time SAQ A-EP compliance typically takes 3-6 months for a small e-commerce operation, longer if significant infrastructure changes are needed.
Cost: Budget $5,000-$15,000 for initial gap assessment and remediation, plus $3,000-$8,000 annually for ongoing scanning, testing, and documentation.
The safest path forward in 2026
Given the rapid exploitation of vulnerabilities like the GitLab RCE that compromised 13 organizations across six countries and Cisco zero-days actively exploited within hours of disclosure, the simplest approach is to architect for SAQ A eligibility from the start.
Use fully hosted payment pages. Let Stripe, Square, or PayPal handle the entire payment experience on their domains. Your PCI burden drops to basic security hygiene, and your attack surface shrinks dramatically.
If business requirements demand payment forms on your domain for branding or user experience, invest properly in SAQ A-EP compliance. Half-measures leave you non-compliant and vulnerable.
Vici Tech Solutions helps e-commerce businesses navigate PCI scoping, implement proper payment architectures, and conduct the penetration testing required for SAQ A-EP compliance. If you're uncertain which SAQ applies to your site or need help achieving compliance, reach out to our team for a scoping assessment.