SAQ-A vs. SAQ-A-EP: The "One Letter" Difference That Can Cost You 170+ Security Controls

What is the PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security controls based on security best practice, designed and developed by the major card payment schemes (Visa, MasterCard, American Express, JCB, Diners and Discover) to enhance the security of Account Data and thereby reduce the risk of data compromise and fraud on a global basis.

Who does the PCI DSS apply to?

The PCI DSS applies to all organisations that store, process or transmit payment cardholder data. For online businesses, if you can accept a payment card transaction for goods or services on your eCommerce website (even if you hand the transaction off to your payment processor), then the PCI DSS applies to you.

How to validate your PCI DSS compliance:

There is a single Payment Card Industry Data Security Standard which details all the controls required to be in place in any Cardholder Data Environment (CDE). The CDE is the part of a business that handles all payment card data.

Depending on the type and number of transactions processed you may be asked to either validate your compliance with the PCI DSS via a Self Assessment Questionnaire or to have an Onsite Assessment by a Qualified Security Assessor (QSA). Merchants (a business that accepts payment card transactions) are categorised into one of four levels. Level 1 merchants being the largest and requiring an onsite assessment, through to level 4 merchants who are required to validate their compliance via a Self Assessment Questionnaire.

PCI Compliance for eCommerce Websites

In the world of PCI DSS 4.0, "compliance" is no longer a simple one-size-fits-all checkbox. For e-commerce businesses, the difference between a streamlined assessment and a complex, resource-heavy audit often comes down to just two letters: EP.

Understanding this distinction isn't just about passing an audit—it is about understanding where your legal and security responsibilities begin in an era of increasingly sophisticated "digital skimming" attacks.

The Core Question: Who Controls the Page?

Both SAQ-A and SAQ-A-EP are designed for merchants who outsource payment processing to a PCI DSS-compliant third party (such as Stripe, PayPal, or Adyen). The critical distinction lies in how that payment form is delivered to your customer's browser.

SAQ-A: The "Wall"

Think of SAQ-A as a physical wall between you and the payment.

• The Method: You use an iFrame or a URL Redirect.

• The Experience: When a customer pays, the form they see is hosted entirely by your Payment Service Provider (PSP).

• The Technicality: Your website effectively acts as a "window" to their secure environment.

• The Security Reality: Your website has zero control over what happens inside that window. Because the PSP hosts the page, the risk of card data being intercepted on your site is minimal.

SAQ-A-EP: The "Bridge"

SAQ-A-EP stands for "E-commerce/Partial" outsourcing.

• The Method: This usually happens when you use JavaScript-based forms or Direct Post APIs to create a seamless checkout experience.

• The Experience: The payment fields appear to be a seamless part of your website’s code.

• The Technicality: Even though the data still goes directly to the payment provider, your website code is what built the form and created the "instructions" for that data flow.

• The Security Reality: You have built a bridge, and you are responsible for making sure no one is hiding under it. Because your website controls the delivery of the form, a hacker who compromises your site could alter those instructions to send data to a malicious server instead

Technical Comparison: The Operational Burden

The jump from SAQ-A to SAQ-A-EP is not a minor step; it is an exponential increase in workload.

Why This Matters: Lessons from Recent Breaches

You might wonder: "If I never store the card data, why does PCI care so much about my website security?". Recent history shows that hackers don't need to touch your server to steal your customers' money. They use a technique called Digital Skimming (or Magecart attacks).

The "Bybit" Heist (February 2025)

While a crypto-exchange, this $1.5 billion breach exploited third-party storage and malicious JavaScript to manipulate transactions. For an e-commerce merchant, a similar script could be used to "skim" card details from an SAQ-A-EP form before they are ever encrypted.

Supply Chain Attacks

Attackers are increasingly targeting the third-party plugins you use, such as chat bots, analytics, or marketing pixels. If these scripts are compromised on your payment page, they can capture keystrokes in real-time as users type their sensitive details.

New PCI DSS 4.0 Rules for E-Commerce

Under the new 4.0 standard, the "A-EP" designation carries significant new weight. Merchants are now required to implement active monitoring for client-side scripts:

• Manage All Scripts (Requirement 6.4.3): You must maintain a full, authorized inventory of every script running on your payment page.

• Detect Tampering (Requirement 11.6.1): You must implement tools to alert you immediately if your payment page code or HTTP headers are changed without authorization.
  
  

Decision Checklist: Which Path Are You On?

1. The Redirection Test

• SAQ-A: When your customer clicks "Pay," are they sent to a URL that starts with your provider's domain (e.g., https://checkout.stripe.com/...)?

• SAQ-A-EP: Does the URL in the browser remain your domain (e.g., https://yourstore.com/checkout) throughout the entire process?

2. The Form Delivery Test

• SAQ-A: Do you use an iFrame where the payment fields are essentially a "window" hosted by your provider?

• SAQ-A-EP: Do you use JavaScript (like a custom form that "posts" data to an API) to capture card details?

3. The "Script" Factor (New for PCI 4.0.1)

• Critical Check: Do you have third-party scripts (chat bots, analytics, heatmaps) running on your checkout page?
• The Trap: Even if you think you are SAQ-A, new 4.0.1 standards require you to prove these scripts cannot "see" or "skim" the payment window. If you cannot verify this, you may be pushed into the stricter SAQ-A-EP category.
  
  

How We Help

Moving from 31 requirements to nearly 200 is a massive operational burden, with significant financial impact. Don't guess your scope; ensure you're on the right path before your compliance deadline.

Our QSA-certified team provides the technical guidance needed to secure your environment while minimizing your compliance overhead.

Learn more about our PCI DSS compliance services for merchants.