Ecommerce PCI compliance determines which security controls your organization must implement, how much your annual assessment costs, and how vulnerable you are to regulatory penalties after a breach. The January 2025 SAQ A revision and the March 2025 enforcement of PCI DSS v4.0’s future-dated requirements changed the compliance calculus for online merchants, particularly those using iframe payment integrations.
What PCI DSS means for ecommerce merchants
The Payment Card Industry Data Security Standard applies to any organization that processes, stores, or transmits cardholder data. For ecommerce merchants, this means every system that touches card numbers, CVVs, or cardholder names falls within your Cardholder Data Environment (CDE) and must meet the standard’s security controls.
According to IBM Security’s 2024 Cost of a Data Breach Report, the average breach cost reached $4.88 million globally, with US breaches averaging $9.36 million. For payment-specific breaches, you also face fines from card networks ranging from $5,000-$10,000 per month initially, escalating to $100,000 per month after six months of non-compliance. Breach-related fees run $50-$90 per compromised cardholder record.
Ecommerce is specifically targeted. Recorded Future’s 2024 Payment Fraud Report found 11,000 unique ecommerce domains infected with Magecart e-skimmers, a threefold increase from 2023. Card-not-present fraud now accounts for 71% of all US card fraud losses, approximately $10 billion annually. Customers who transact at e-skimmer-infected merchant sites are 31% more likely to become fraud victims, according to Mastercard incident data.
The ecommerce-specific risk profile explains why PCI DSS v4.0 introduced new requirements targeting payment page security, and why compliance officers should pay close attention to how their payment integrations are architected.
PCI compliance levels and SAQ types for online stores
Your compliance level determines your validation requirements. Transaction volume dictates level; integration architecture dictates SAQ type.
| Level | Annual card transactions | Validation requirement |
|---|---|---|
| Level 1 | Over 6 million | Annual Report on Compliance (ROC) by QSA, quarterly ASV scans, annual penetration test |
| Level 2 | 1-6 million | Annual SAQ, quarterly ASV scans, QSA/ISA may be required for high-risk SAQ types |
| Level 3 | 20,000-1 million ecommerce | Annual SAQ, quarterly ASV scans |
| Level 4 | Under 20,000 ecommerce or under 1 million total | Annual SAQ, quarterly ASV scans (requirements vary by acquirer) |
The distinction between SAQ types matters more than compliance level for most ecommerce merchants. SAQ A contains 31 questions. SAQ D for merchants contains 328 questions. The difference represents months of assessment work, significantly higher audit costs, and more systems requiring security controls.
SAQ A vs. SAQ A-EP vs. SAQ D: which applies to you?
SAQ type depends on how your payment integration handles cardholder data, not on transaction volume or business size.
| SAQ type | Requirements | When it applies |
|---|---|---|
| SAQ A | 31 | All payment processing fully outsourced to a PCI DSS-compliant TPSP; card data never touches your systems (redirects or iframes) |
| SAQ A-EP | 139 | You host the payment page but don’t store cardholder data; your systems control the page where customers enter card details |
| SAQ D | 328 | You store, process, or transmit cardholder data directly; card data passes through your infrastructure |
The difference between SAQ A and SAQ D represents a 90% reduction in compliance scope.
A payment orchestration platform that tokenizes card data before it reaches your systems shifts the compliance burden from your organization to the platform.
PCI DSS v4.0: new requirements for ecommerce (6.4.3 and 11.6.1)
PCI DSS v4.0 introduced two requirements specifically addressing ecommerce payment page security. Both became mandatory on March 31, 2025.
Requirement 6.4.3: Payment page script management
You must maintain an inventory of all scripts executed on your payment pages, document authorization for each script, and implement integrity verification. This covers every JavaScript file, inline script, and third-party tag that loads in the consumer’s browser during checkout.
The requirement exists because Magecart attacks inject malicious scripts that capture card data as customers type. Visa’s PERC Biannual Report (Spring 2025) noted a 7% increase in websites identified as infected with digital skimming malware. Script inventory and authorization controls make unauthorized scripts detectable.
Requirement 11.6.1: Payment page tamper detection
You must deploy change and tamper detection mechanisms for payment pages. These mechanisms must:
- Alert on unauthorized modifications to HTTP headers and script contents
- Evaluate pages as received by the consumer browser DOM
- Run at minimum weekly (or per a targeted risk analysis under Requirement 12.3.1)
This requirement addresses attacks that modify legitimate scripts or inject content through compromised CDNs and tag managers. Weekly monitoring is the default; more frequent monitoring reduces detection time for active attacks.
For a complete mapping of all 12 PCI DSS requirements, including implementation guidance, see our detailed checklist.
The January 2025 SAQ A eligibility changes
On January 30, 2025, the PCI Security Standards Council published SAQ A r1, revising eligibility criteria for ecommerce merchants. This change directly impacts merchants using iframe payment integrations.
Previously, iframe implementations qualified for SAQ A based on the assumption that browser security models isolated the embedded payment form from the merchant’s page. The January 2025 revision acknowledges that this isolation isn’t absolute: scripts on the parent page can potentially interact with iframe content under certain conditions.
The two paths to SAQ A eligibility
Merchants using embedded payment pages (iframes) must now meet one of two criteria:
- Implement Requirements 6.4.3 and 11.6.1 yourself on your merchant page containing the iframe. This means maintaining script inventory, authorization, integrity checks, and tamper detection on your checkout page.
- Obtain written confirmation from your TPSP that the embedded payment solution includes built-in protections against script attacks when implemented according to the TPSP’s instructions.
Redirect implementations, where customers navigate entirely to the payment provider’s domain to enter card details, don’t require either option. The browser security model provides complete isolation when the payment page is on a different origin.
What this means in practice
If your payment integration uses iframes and your payment provider hasn’t issued confirmation of script attack protections, you have two choices: implement 6.4.3 and 11.6.1 yourself, or shift to SAQ A-EP. The latter means going from 31 requirements to 139.
This is why vendor selection matters for compliance officers. A payment compliance outsourcing arrangement should include explicit documentation of what the provider covers under the January 2025 criteria.
Scope reduction through tokenization and payment orchestration
Scope reduction is the most effective strategy for managing PCI compliance cost and complexity. Every system removed from your CDE is a system that doesn’t require security controls, documentation, vulnerability scanning, and assessment.
Tokenization is the primary mechanism. When card data goes directly from the customer’s browser to a tokenization service, and your systems only receive a non-sensitive token, those systems are outside PCI scope. The token has no value to attackers, so systems handling tokens don’t require the same controls as systems handling card data.
Quantifying scope reduction
Moving from SAQ D to SAQ A through tokenization reduces your compliance requirements by 90%. According to Petronella Cybersecurity’s analysis, organizations implementing tokenization alongside payment orchestration achieve 60-80% compliance cost reduction.
Annual compliance costs vary significantly by scope:
| Scope | Typical annual cost |
|---|---|
| SAQ-eligible small business | $300-$10,000 |
| Enterprise (QSA audit required) | $50,000+ |
The cost differential between SAQ A and SAQ D spans this entire range.
How payment orchestration affects scope
A common concern among compliance officers is that adding vendors expands the CDE. The opposite can be true when the vendor handles tokenization before data reaches your systems.
Payment orchestration platforms that capture card data through their own hosted fields or redirects, tokenize immediately, and return only tokens to your systems can reduce your scope rather than expand it. Your systems never see card data, so they’re outside the CDE boundary.
This requires verification. You should request data flow diagrams showing exactly where card data enters, transits, and rests. Marketing claims about “zero PCI scope” need supporting documentation: what tokenization method, where does the token exchange happen, and what SAQ type does this architecture actually enable?
3D Secure authentication requirements add another dimension. Under PCI DSS v4.0 and regional regulations like PSD2’s Strong Customer Authentication, authentication handling must also be assessed for compliance impact.
Documentation requirements for your annual assessment
Compliance assessment requires evidence, not claims. The specific documentation you need depends on your SAQ type, but certain categories apply universally.
Core documentation
- Policies and procedures covering data handling, access control, incident response, and security awareness. These should be current (reviewed within 12 months) and specific to your payment environment.
- Network diagrams showing cardholder data flows. For compliance officers evaluating vendors, these diagrams should clearly identify CDE boundaries, encryption points, and tokenization locations.
- Access control logs demonstrating that access to payment systems follows least-privilege principles and that all access is individually attributable.
- Vulnerability scan reports from an Approved Scanning Vendor (ASV). Quarterly external scans are required for all SAQ types. Internal scanning requirements depend on your specific SAQ.
- Penetration test results for Level 1 merchants and those on certain SAQ types. The test scope must cover the CDE and segmentation controls.
- Training records demonstrating that personnel with access to payment systems have received security awareness training.
For vendor evaluation
When evaluating payment providers, compliance officers should request:
- Current Attestation of Compliance (AOC) with date, assessor name, and scope
- SOC 2 Type II report covering security, availability, and confidentiality
- Data flow diagrams specific to your proposed integration
- Completed security questionnaire (SIG, CAIQ, or your organization’s standard VSQ)
- Shared responsibility documentation explicitly stating what the vendor covers and what remains your obligation
- For iframe implementations: written confirmation regarding January 2025 SAQ A eligibility criteria
The evaluation cycle runs 4-12 weeks and should proceed in parallel with technical evaluation. Missing compliance documentation can block deployment that engineering has already approved.
Frequently asked questions
How does using a payment orchestration platform affect my PCI DSS scope?
If the platform tokenizes card data before it reaches your systems, you can qualify for SAQ A (31 requirements) instead of SAQ D (328 requirements). This represents up to 90% scope reduction. The key is ensuring your systems never handle raw card data; verification requires reviewing data flow diagrams and confirming the tokenization architecture with your provider.
What SAQ type do ecommerce merchants typically need?
Merchants using redirects or iframes from PCI DSS-compliant TPSPs typically qualify for SAQ A (31 requirements). Those hosting payment pages on their own servers but not storing card data need SAQ A-EP (139 requirements). Direct API integrations where card data passes through your infrastructure require SAQ D (328 requirements).
What are PCI DSS Requirements 6.4.3 and 11.6.1?
Requirement 6.4.3 mandates maintaining an inventory of all scripts on payment pages, documenting authorization for each script, and implementing integrity verification. Requirement 11.6.1 requires tamper detection for payment pages that alerts on unauthorized modifications, with at least weekly monitoring. Both became mandatory March 31, 2025.
What changed in the January 2025 SAQ A update?
Merchants using iframe payment integrations must now either implement Requirements 6.4.3 and 11.6.1 on their merchant page themselves, or obtain written confirmation from their TPSP that the embedded solution includes script attack protections. Redirect implementations remain eligible without additional requirements.
What documentation do I need for an ecommerce PCI assessment?
Required documentation includes security policies and procedures, network diagrams showing cardholder data flows, access control logs, quarterly ASV vulnerability scan reports, penetration test results (for Level 1), training records, and your completed SAQ with Attestation of Compliance. For vendor evaluations, also request the provider’s AOC, SOC 2 Type II report, and shared responsibility documentation.
What are the penalties for PCI non-compliance?
Fines from card networks range from $5,000-$10,000 per month initially, escalating to $25,000-$50,000 per month after three months, and up to $100,000 per month after six months of continued non-compliance. Beyond fines, you risk losing card processing privileges entirely and bear full liability for breach costs, which average $4.88 million globally.
