Glossary · Compliance

What is
PCI SAQ A-EP?

Complexity Basic
Shows up Monthly
Scope Network-native
Operator relevance Context
Share definition X LinkedIn Reddit HN Email
Quick definition

SAQ A-EP is the PCI self-assessment questionnaire for e-commerce merchants who outsource payment processing but whose website controls how the cardholder is redirected to the processor — like a hosted-field iframe or a redirect with merchant-controlled JavaScript. Stricter than SAQ A, looser than SAQ D.

The short answer

SAQ A-EP is one of the Self-Assessment Questionnaires under PCI DSS. It applies specifically to e-commerce merchants who outsource card processing to a PCI-validated third party, BUT whose website is still in the cardholder data path — for example, the merchant's server delivers the JavaScript that loads the payment iframe, or runs a redirect script that could be tampered with. "EP" stands for "E-commerce Partially outsourced."

The three e-commerce SAQs — how they split

  • SAQ A (~22 questions). Fully outsourced. The payment page is hosted by the processor on their domain. Your site only has a button/link to it. Easiest path.
  • SAQ A-EP (~191 questions). Partially outsourced. Your site loads the iframe or runs the redirect. You can indirectly affect payment pages. Medium path.
  • SAQ D (~329 questions). You touch or could touch card data. Heaviest path.

See also SAQ A vs SAQ D for the fully-outsourced comparison.

When A-EP applies to you

  • You embed a Stripe Elements / Braintree Hosted Fields / Authorize.net Accept.js iframe on your own checkout page.
  • You use a merchant-controlled JavaScript redirect to the processor.
  • Your server sends the payment page HTML that then loads the processor iframe.
  • Any scenario where a compromise of your web server could allow an attacker to modify the card-entry flow.

What A-EP requires that A doesn't

  • Quarterly external vulnerability scans by an ASV (approved scanning vendor).
  • File-integrity monitoring on the web server.
  • Change-management procedures for any payment-page code.
  • Script integrity (PCI DSS 4.0 requirement 6.4.3) — subresource integrity or equivalent on all scripts in the payment-page DOM.
  • Logging and monitoring of the web server for 90 days online, 1 year archived.
  • Annual internal vulnerability scan.
  • Formal incident-response plan and testing.

What operators need to know

  • PCI 4.0 expanded A-EP. As of March 2025, the requirement for client-side script integrity (6.4.3) and HTTP header tampering detection (11.6.1) landed. Hosted Fields merchants can't skip these anymore.
  • Moving to SAQ A cuts your audit burden by ~85%. The path is either a full-page processor redirect or a properly-wrapped iframe on a processor domain. Worth the UX trade-off for many operators.
  • Multi-brand multiplies scope. Every brand has its own checkout and every checkout is in A-EP scope separately. Routing through one consolidated checkout layer (like multiflow) keeps the PCI surface area at one SAQ, not N.
  • ASV scan failures block renewal. Your acquirer will ask for the passing ASV report annually. Missing it can suspend processing.

Related glossary terms

Processing across
multiple brands?

multiflow consolidates your ledger, keeps per-brand billing descriptors, and fans out payouts to the right legal entity.

The Operator Briefing

Twice-monthly. No fluff.

Processor shutdowns, reserve-hold playbooks, reconciliation lessons, and the merchant-account decisions that save operators six-figure years. Delivered to your inbox — never spam.

No spam. Unsubscribe in one click.

We use essential cookies · Privacy