SAQ A-EP walkthrough: e-commerce that partly controls the payment
By Sam Rivera, Founder, SentinelPanda · June 3, 2026 · 3 min read · PCI DSS
SAQ A-EP is what you actually need when your payment page is "mostly outsourced." Substantially heavier than A; substantially shorter than D.
Who SAQ A-EP is for
SAQ A-EP applies to e-commerce merchants whose website affects the security of cardholder data, but where cardholder data is not stored, processed, or transmitted by the merchant's systems. The classic example: you use Stripe Elements, where the card fields are iframes hosted by Stripe but your JavaScript orchestrates the payment, applies styling, and submits the token to Stripe.
The defining test is whether your site can affect how the payment data is collected. If yes (your code styles or scripts the iframe, your code calls a tokenisation library, your DOM contains the payment form), you are A-EP. If no (the customer is fully redirected away and your site has no connection to the payment data collection), you are A.
The eligibility checklist
- You accept e-commerce payments only.
- All elements of payment pages are delivered via your site, but cardholder data is collected by a PCI-validated TPSP.
- Your site does not receive, store, process, or transmit cardholder data — it only orchestrates collection.
- You confirm annually that your TPSP's PCI DSS compliance status is current.
- Your e-commerce site is segmented from any other payment channel.
What changed in 4.0.1 for SAQ A-EP
A-EP merchants carry the same script and integrity requirements as SAQ A — Req 6.4.3 (script inventory) and Req 11.6.1 (page-integrity monitoring) — but they are far more critical here because your code IS on the payment page. A page-skimmer attack that injects malicious script into your A-EP page can capture card data before it reaches the iframe.
In practice: a hardened Content Security Policy that lists every allowed script source; a Subresource Integrity (SRI) check on every script you load; automated monitoring that alerts when the page hash or script set changes unexpectedly. The 4.0.1 mandate is documented capability; the actual security need is real.
The requirement subset
A-EP is substantially larger than A — typically 80+ control questions covering Requirements 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, and 12 with carve-outs. The biggest blocks are Req 6 (secure software development and patch management for the e-commerce platform), Req 10 (logging and monitoring), and Req 11 (vulnerability management, ASV scans).
You need quarterly ASV scans of every internet-facing system in the e-commerce environment. You need a documented secure SDLC for changes to the e-commerce code. You need access controls and audit logging on the systems that host the payment page. You need vulnerability scanning and penetration testing of the e-commerce environment.
Common SAQ A-EP pitfalls
- Treating A-EP like A and skipping ASV scans, logging, or vulnerability management.
- A weak or absent Content Security Policy on the payment page — a major page-skimmer risk.
- Loading scripts from sources you do not control (broad CDN allowlists, tag managers with no inventory).
- Conflating dev and prod payment pages — using a dev script bundle in production accidentally.
- Forgetting Req 6.4.3 inventory items that are loaded by tag managers, A/B test frameworks, or marketing scripts.
A worked example
You run a Next.js storefront integrated with Stripe Elements. The card-number, expiry, and CVV inputs are Stripe-hosted iframes; your code wires them up and calls the tokenisation API. Your CI builds the storefront from a locked dependency set; every script is SRI-verified; CSP locks script-src to known origins; an automated job re-checks the deployed payment-page hash hourly. You run quarterly ASV scans of the storefront origin, monthly internal vulnerability scans, and an annual penetration test.
Your SAQ A-EP walks Req 6.4.3 and 11.6.1 in detail, the Req 8/10 controls for your e-commerce platform admin accounts, the Req 11 ASV evidence, and the Req 12 policies plus TPSP attestations. Total: 4-8 weeks first time, 2-3 weeks revalidation.