SAQ A-EP is the PCI DSS Self-Assessment Questionnaire for e-commerce merchants that outsource card processing to a PCI DSS compliant third party but still control part of the payment experience. Typically that means your website redirects the customer, or builds the page around the payment form. You qualify only if every eligibility criterion is met. You then answer a much longer list of controls than SAQ A asks for, including script management, tamper detection, quarterly external scans and penetration testing. This guide covers each of those, so you can tell which questionnaire you owe and what the answer costs you in effort.
The PCI Security Standards Council describes SAQ A-EP as the questionnaire for e-commerce merchants that partially outsource their payment channel to validated third parties and do not electronically store, process or transmit account data on their own systems or premises. It applies to e-commerce channels only. It is not a service provider questionnaire.
The “EP” matters. Your website does not receive card data, but it influences how the transaction happens. If an attacker alters your page, they can redirect the customer or capture the card number before it reaches the processor. SAQ A-EP exists because that influence puts your web server, your code and your page scripts in scope.
The Council published the current SAQs for PCI DSS v4.0.1 on 15 October 2024. The update bulletin lists clarified eligibility criteria for SAQs A, A-EP and C-VT, and updated completion guidance for SAQs A and A-EP.
All criteria must be met. Meeting most of them does not count. The PCI SSC’s own eligibility FAQ states that a merchant whose payment page elements all come from a compliant provider still cannot use SAQ A or A-EP if it misses any other criterion.
According to the SAQ A-EP document, you must meet these conditions:
Two practical points follow. First, “originates from your website” is the phrase that separates A-EP from SAQ A. Second, the Attestation of Compliance review is an active step: you need the current document from each provider and a check that its scope covers the service you actually use.
The line between the two is the payment page. If everything the customer’s browser receives on the payment page comes directly from your compliant third party, you are in SAQ A territory. If your own server delivers any part of the page, or your site controls the redirect, you are in A-EP territory.
SecurityMetrics security analyst Michael Maughan puts the difference in the qualifying criteria: A-EP is for merchants whose e-commerce card data flow is not entirely outsourced to a validated third party. Under v4.0, SAQ A carries 33 requirements and SAQ A-EP carries 151. That gap is why many merchants redesign their checkout to qualify for the shorter form.
| Factor | SAQ A | SAQ A-EP |
|---|---|---|
| Channels | E-commerce, or mail order/telephone order | E-commerce only |
| Payment page | Every element comes only and directly from a compliant third party | Elements may come from your site or a compliant TPSP |
| Website role | No role in handling account data | Does not receive data but controls the redirect |
| Requirement count (v4.0) | 33 | 151 |
| Scripts (6.4.3, 11.6.1) | Removed; replaced by an eligibility criterion | In force |
| External scans | Not part of the form’s controls | Quarterly by an ASV |
The SAQ A row on scripts is a recent change. The Council’s March 2025 podcast explains that Requirements 6.4.3, 11.6.1 and 12.3.1 were removed from SAQ A, and a new eligibility criterion was added. Under it, you confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems. A-EP merchants get no such relief. For them the script controls remain.
SAQ A-EP is also one of only three questionnaires that can be used for an e-commerce channel, according to URM Consulting. The other two are SAQ A and SAQ D. If A-EP does not fit, the next stop is D, which is far larger.
SAQ A-EP draws on a broad set of PCI DSS requirements, because your web server is in scope. One security vendor counts approximately 140 applicable controls, with quarterly ASV scans and penetration testing for components that can affect payment page behavior. SecurityMetrics counts 22 additions in v4.0 covering script management, multi-factor authentication and change detection. Confirm the exact count in the questionnaire for the version you are using, since the numbers shift with each revision.
The controls cluster into several groups.
The PCI SSC’s payment page security guidance says that every script loaded and executed in the consumer’s browser must be managed in three ways:
Where it goes wrong: tag managers, analytics pixels, chat widgets and A/B testing tools. Marketing teams add them without telling engineering, and the inventory goes stale the first week. An inventory is only useful when adding a script requires a change record with a named owner and a stated reason.
The same guidance requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of security-impacting HTTP headers and script contents, as received by the consumer’s browser. It must run at least weekly, or at the frequency set in your targeted risk analysis under Requirement 12.3.1.
Note what is being watched: the page as the browser receives it, not only your source code repository. A compromised third-party script can change what the browser executes while your repository stays clean. That is why server-side file integrity monitoring alone does not satisfy this control.
The SAQ A-EP document specifies external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor (ASV). Passing scan reports are part of what you may be asked to submit with the questionnaire. Penetration testing applies to the components that can affect the payment page, per the same SAQ structure.
A scan that fails on a newly found vulnerability does not have to wait until the next quarter. Fix, rescan and keep the passing report with your compliance file.
The remaining sections cover familiar PCI DSS ground: secure configuration of systems, patching, access control and multi-factor authentication, logging and monitoring, and security policies. Because your web server delivers or controls the payment experience, it must be hardened and monitored as a system in scope. The PCI DSS 4.0 changes on our site walk through the v4.0 additions in plain terms, and our PCI compliance checklist for B2B merchants gives you a working list to adapt.
Many merchants assume an embedded payment form moves all script risk to the provider. It moves part of it. The PCI SSC guidance clarifies that for an iframe, your responsibility under 6.4.3 and 11.6.1 covers scripts on your own page that contains the iframe. The TPSP’s responsibility covers scripts inside the iframe it provides.
In the Council’s podcast, the confirmation that a site is not susceptible to script-based attacks can come two ways. You can apply techniques such as those in Requirements 6.4.3 and 11.6.1 to protect your page, or you can obtain confirmation from the compliant TPSP that provides the embedded iframe.
Three common setups, and where they usually land:
Your website’s role in the data flow, not the checkout’s appearance, decides the questionnaire. Two checkouts that look identical to a shopper can sit in different SAQs.
The SAQ A-EP document lays out the process. Here it is with the points where merchants stumble.
The PCI SSC bulletin also encourages every entity completing an SAQ to contact the receiving organization first. Confirm that you are eligible to validate with an SAQ and ask for any specific instructions. Merchant levels and validation rules are set by the card brands and your acquirer, not by the questionnaire.
One level-specific point: the SAQ A-EP document notes that for Level 2 merchants it is treated as a high security risk SAQ, and engagement of a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) may be required for validation. Ask your acquirer which applies to your volume.
Treat the attestation as a yearly cycle with quarterly scans in between. The first year costs the most, because it includes building the script inventory and the monitoring process. Later years mostly refresh evidence.
The SAQ A-EP document is direct about this: when PCI DSS requirements that apply to your cardholder data environment are not covered in the questionnaire, it may not be suitable for you. Confirm eligibility before you start and ask your acquirer for guidance.
In practice you have two directions:
If you are in the second group for a new gateway integration, decide before development starts. Rebuilding a checkout after launch costs far more than choosing the integration pattern early.
Merchants often arrive at SAQ A-EP by accident. A developer builds a custom checkout page, the page posts to a gateway, and months later someone discovers that 151 requirements now apply. We think the order should run the other way: decide how much of the payment experience you want to own, then choose the integration that matches.
That decision belongs in the processor conversation. At CARDZ3N we place merchants with sponsor-bank-backed accounts and integrate payment gateways with leading platforms, so the integration pattern and the compliance footprint can be settled together. High-risk and subscription merchants feel this most, because their volume, chargeback exposure and card-brand scrutiny make a clean PCI posture part of staying approved.
Our advice on A-EP specifically: if you take it, treat 6.4.3 and 11.6.1 as operating procedures, not paperwork. Name an owner for the script inventory, run the weekly tamper check on a schedule, and keep the evidence. If you can legitimately reduce scope to SAQ A, do the engineering and meet its criteria honestly.
Joshua Benedetti
If you are choosing or changing a processor, the integration method determines your SAQ. Our team handles payment gateway integrations and online payment processing for merchants, including those that Stripe, PayPal or Square have rejected or shut down. We are transparent about reserve structures and quote-based pricing. Tell us how your checkout works, and we will place the account on an integration that fits it. For subscription, CBD, adult and other high-risk categories, start with our high risk merchant account page.
It is the Self-Assessment Questionnaire for e-commerce merchants that partially outsource payment processing. The “EP” refers to the merchant website’s role in the e-commerce payment flow. Your site does not receive card data, but it controls how customers are redirected to the processor or delivers elements of the payment page.
Under PCI DSS v4.0, SecurityMetrics counts 151 requirements in SAQ A-EP against 33 in SAQ A. Counts can change between versions, so confirm against the current questionnaire. The 6.4.3 and 11.6.1 script controls apply to A-EP, and external scans must be run quarterly by an ASV.
Possibly, if every payment page element originates only and directly from a PCI DSS compliant third party and you meet all other SAQ A criteria. That includes confirming your site is not susceptible to script-based attacks. If any element of the payment page comes from your own server, A-EP is the likelier fit. Confirm with your acquirer.
You submit the SAQ and Attestation of Compliance to the organization requesting it, usually your acquirer or the payment brands, along with documents such as ASV scan reports. The PCI SSC recommends contacting that organization before you start, to confirm that you may validate with an SAQ.
Every merchant's processing setup is different, so the right answer depends on your industry, sales channels, average ticket size and chargeback history. CARDZ3N's payments specialists review those details with you and match your business with the right sponsor bank, gateway and risk tools, whether you sell online, in store, by invoice or on a recurring subscription.
We work with merchants across the USA, Canada, the UK and the EU, including high-risk, B2B and fast-growing businesses that traditional processors often turn away. If you would like a second opinion on your current rates, contract terms or approval options, contact our team for a free, no-obligation processing review.
Joshua Benedetti is the CEO of CARDZ3N, a Las Vegas-based merchant services provider specializing in high-risk payment processing and B2B payment technology.
Joshua Benedetti on LinkedInCARDZ3N Inc is headquartered in Las Vegas, Nevada, and provides merchant services to businesses that traditional processors turn away. Backed by top-tier sponsor banks and processors, CARDZ3N combines institutional stability with the speed of a specialized team that understands high-risk industries. Services include high-risk account underwriting and placement, gateway solutions across the major gateway platforms, POS integrations, ACH and check processing, chargeback prevention through ChargebackZ3N, and business lending and working capital. Its AerospacePay division serves OEMs, MROs, FBOs, and repair stations with B2B and B2G payment processing. CARDZ3N serves merchants in the USA, Canada, the UK, and the EU.
Start protecting your revenue from chargebacks today — schedule your complimentary consultation with CARDZ3N’s dispute management specialists.
