What is the key difference between SAQ A and SAQ A-EP?

The critical difference is whether your website can affect the security of the payment transaction. SAQ A applies when the entire payment page is hosted by a third-party processor (redirect or iframe) and your site has no code that could impact payment data. SAQ A-EP applies when your website controls how cardholder data is redirected or transmitted — for example, using JavaScript-based payment forms, direct post methods, or any implementation where your website code interacts with cardholder data before it reaches the processor.

Why does SAQ A-EP have significantly more requirements than SAQ A?

SAQ A-EP includes approximately 139 requirements compared to SAQ A's 22 because your website is in scope for the payment transaction. Since your web application code can affect the security of cardholder data transmission, you must implement web application security controls (Requirement 6), network security (Requirement 1), vulnerability management (Requirement 11), and other protections that SAQ A merchants do not need. Your web servers and the code running on them become part of the cardholder data environment.

Does using a JavaScript payment library like Stripe.js mean I need SAQ A-EP?

Generally, yes. When you include a JavaScript library from a payment processor that renders payment fields on your page (even if the fields are technically hosted by the processor), your website code controls the loading and execution of that script. If your page JavaScript could be compromised to intercept or redirect payment data, you typically fall under SAQ A-EP. However, the exact determination depends on the specific implementation — consult your payment processor and acquirer for definitive guidance.

What web security requirements does SAQ A-EP include?

SAQ A-EP includes extensive web application security requirements under Requirement 6, including secure development practices, code reviews, web application firewalls (WAF), and client-side script management (6.4.3). It also requires network security controls (Requirement 1), vulnerability scanning and penetration testing (Requirement 11), access controls (Requirements 7 and 8), and physical security (Requirement 9). Essentially, your entire web application infrastructure is in scope.

Can I move from SAQ A-EP back to SAQ A by changing my payment integration?

Yes. If you change your payment integration from a JavaScript-based approach (like direct post or hosted fields) to a full redirect or properly implemented iframe where your website cannot affect payment data security, you may qualify for SAQ A instead. This is a common architectural decision for e-commerce merchants looking to reduce their PCI DSS compliance scope. GRCTrack's SAQ selection wizard can help you evaluate whether your new implementation qualifies for the simpler SAQ A.

← All SAQ Types

SAQ A-EP — E-Commerce Partial Outsource

PCI DSS SAQ A-EP Compliance Guide

The self-assessment for e-commerce merchants whose websites affect payment data security — significantly more rigorous than SAQ A.

Understand when SAQ A-EP applies, the web security requirements involved, and how GRCTrack helps you navigate this demanding compliance path.

Start Your SAQ A-EP Assessment Talk to a PCI Expert

What Is SAQ A-EP?

SAQ A-EP (E-Commerce Partially outsourced) is designed for e-commerce merchants who partially outsource their payment processing but whose website still plays a role in the security of the payment transaction. Unlike SAQ A merchants who fully outsource, SAQ A-EP merchants have website elements — typically JavaScript code — that control how cardholder data is transmitted to the payment processor.

This SAQ applies when the merchant's website does not receive cardholder data directly, but the merchant's web server and application code can affect the integrity and security of the payment page. Common scenarios include using JavaScript-based payment forms (like Stripe Elements or Braintree hosted fields), direct post integrations, and any implementation where the merchant's page code loads or controls payment-related scripts.

With approximately 139 requirements, SAQ A-EP is substantially more demanding than SAQ A's 22 requirements. This reflects the increased risk that comes with having website code that could be compromised to intercept or redirect payment data. Merchants must implement web application security, network protection, vulnerability management, and comprehensive access controls.

Who Qualifies for SAQ A-EP?

E-commerce merchants using JavaScript-based payment forms (Stripe Elements, Braintree hosted fields)

Merchants using direct post methods where cardholder data is sent from the browser to the processor

Merchants whose website code loads scripts that control payment page rendering

E-commerce sites where page JavaScript could potentially intercept or redirect payment data

Merchants who do not electronically store, process, or transmit CHD on their own servers

All payment processing is outsourced to a PCI DSS validated third-party processor

Key SAQ A-EP Requirement Areas

Req 1: Network Security

Install and maintain network security controls including firewalls and network segmentation to protect your web servers and payment page infrastructure.

Req 2: Secure Configurations

Apply secure configurations to all system components including web servers, application servers, and any infrastructure that hosts or delivers payment pages.

Req 6: Secure Development

Develop and maintain secure systems and software. Includes secure coding practices, code reviews, web application firewalls, and client-side script management (6.4.3).

Req 7 & 8: Access Controls

Restrict access to system components by business need-to-know and identify and authenticate all users. Strong authentication is required for all access to web application infrastructure.

Req 11: Security Testing

Regularly test security systems including ASV scans, penetration testing, intrusion detection, and payment page change-and-tamper-detection mechanisms (11.6.1).

Req 9 & 12: Physical & Policy

Restrict physical access to system components, maintain security policies, manage third-party relationships, and implement security awareness training.

Common SAQ A-EP Mistakes

Thinking SAQ A Applies When Using JavaScript Forms

The most common mistake is assuming that because cardholder data goes directly to the processor, SAQ A applies. If your website loads JavaScript that controls how payment fields are rendered or how data is transmitted, your site can affect payment security, making SAQ A-EP the correct choice.

Not Understanding Redirect vs. Iframe Triggers

Merchants often conflate redirect and iframe implementations. A true redirect takes the customer to the processor's domain. An iframe embeds the processor's page. Both can qualify for SAQ A — but if your page JavaScript interacts with either, you may need SAQ A-EP. The technical implementation details, not the visual appearance, determine the correct SAQ.

Missing Req 6.4.3 Client-Side Script Management

PCI DSS v4.0.1 requires merchants to maintain an inventory of all scripts loaded on payment pages, justify each script, and implement integrity monitoring. Many SAQ A-EP merchants underestimate this requirement, particularly when using third-party analytics, tag managers, or advertising scripts on checkout pages.

Failing Web Application Firewall Requirements

SAQ A-EP requires a web application firewall (WAF) or equivalent protection for web-facing applications. Merchants who rely solely on network firewalls without implementing application-layer protection fail to meet Requirement 6.4 and leave their payment pages vulnerable to application-level attacks.

How GRCTrack Helps with SAQ A-EP Compliance

SAQ type selection wizard that differentiates SAQ A from SAQ A-EP based on your payment integration

Complete SAQ A-EP control library with all 139 requirements mapped, guided, and evidence-linked

Web application security guidance for Req 6 including WAF implementation and secure coding checklists

Client-side script inventory management for Req 6.4.3 with monitoring implementation guidance

Vulnerability scan and penetration test scheduling with ASV integration for Req 11 compliance

AI-powered compliance guidance built by certified QSAs to help navigate SAQ A-EP complexities

SAQ A-EP Compliance — Frequently Asked Questions

Related PCI DSS Resources

All SAQ Types PCI DSS 4.0.1 Guide SAQ A Guide E-Commerce Guide

Ready to Complete Your SAQ A-EP Assessment?

GRCTrack guides e-commerce merchants through every SAQ A-EP requirement with expert-built compliance workflows.

Start Your SAQ A-EP Assessment Compare SAQ Types