PCI DSS Compliancefor E-Commerce
Navigate the complexities of online payment security. From payment page architecture to third-party script management, this guide covers everything e-commerce merchants need to achieve and maintain PCI DSS compliance.
Part of our PCI DSS compliance framework →
Overview
E-commerce merchants occupy a unique position in the PCI DSS landscape. Unlike brick-and-mortar retailers where the card is physically present, online merchants must contend with card-not-present fraud, web application vulnerabilities, and the challenge of securing a payment flow that traverses the public internet. The way you architect your payment page determines not only your security posture but also which SAQ applies to your environment and the total number of PCI DSS requirements you must satisfy.
PCI DSS 4.0.1 introduced two requirements that fundamentally affect e-commerce: Requirement 6.4.3 mandates an inventory and integrity verification of all payment page scripts, and Requirement 11.6.1 requires a change-detection mechanism on payment pages. These requirements, fully enforceable from 31 March 2025, mean that every JavaScript file loaded on a page where cardholder data is entered must be authorised, justified, and monitored for tampering.
The stakes are high: Magecart-style attacks, where malicious JavaScript is injected into payment pages to skim card data in real time, have compromised hundreds of thousands of online stores. Understanding your payment architecture options and their PCI implications is the first step toward building a secure e-commerce platform.
Payment Architecture Options
How your e-commerce platform handles payment data collection determines your PCI scope. Here are the four primary models, ordered from lowest to highest scope impact:
Full Redirect (Hosted Payment Page)
Lowest ScopeThe customer is redirected entirely to the payment provider's domain (e.g., Stripe Checkout, PayPal) to enter card details. Your server never touches cardholder data and your web pages never render payment fields. This model typically qualifies for SAQ A, the shortest questionnaire with only 22 requirements. The trade-off is less control over the checkout experience and a visible domain change that may impact conversion rates.
Iframe Embed (Hosted Fields)
Low ScopePayment fields are rendered inside iframes served from the payment provider's domain, embedded within your checkout page. The parent page never has access to the card data inside the iframe (same-origin policy). This preserves your branding while keeping card data off your servers. However, because your page's JavaScript could theoretically overlay or manipulate the iframe, PCI DSS 4.0 considers you in scope for script management (Requirements 6.4.3 and 11.6.1). This model may qualify for SAQ A under the updated 4.0 criteria, provided script integrity controls are in place.
JavaScript-Based Collection (Client-Side Tokenisation)
Medium ScopeA JavaScript library from the payment provider runs on your page and collects card data directly from form fields you render, tokenising it before transmission. Card data briefly exists in the browser's DOM and memory on your domain. This model requires SAQ A-EP because your page's scripts can access the payment data. You must satisfy approximately 139 requirements, including vulnerability scanning, penetration testing, and web application firewall deployment.
Direct Server-Side Processing
Highest ScopeCard data is submitted to your server, which then forwards it to the processor. Your server receives, processes, and potentially stores cardholder data. This places you under SAQ D with all 300+ PCI DSS requirements, or a full ROC for Level 1 merchants. Very few e-commerce merchants need this model, but those providing payment services to other merchants (payment facilitators) often do.
Key Challenges for E-Commerce
1. Third-Party Script Management (Requirement 6.4.3)
Modern e-commerce sites load dozens of third-party scripts: analytics, A/B testing, chat widgets, social media pixels, and advertising tags. Each script loaded on a payment page is a potential attack vector. Requirement 6.4.3 demands a complete inventory of all scripts, written justification for each, and an integrity-verification mechanism such as Subresource Integrity (SRI) hashes or Content Security Policy (CSP) directives. Implementing this without breaking site functionality requires careful planning and ongoing governance.
2. Payment Page Tampering Detection (Requirement 11.6.1)
Beyond script management, Requirement 11.6.1 requires a mechanism to detect unauthorised changes to HTTP headers and payment page content. This means monitoring the actual rendered page for changes that could indicate a Magecart-style injection. Solutions range from server-side content hashing to specialised client-side monitoring tools. The mechanism must alert personnel and operate at least every seven days or upon any detected change.
3. Session Management and Authentication
E-commerce platforms must protect user sessions throughout the checkout flow. Session fixation, session hijacking, and cross-site request forgery (CSRF) attacks can allow attackers to intercept payment data or redirect transactions. Requirement 6.2.4 mandates that web applications handle all input properly, while Requirement 8 requires strong authentication for any administrative access to the e-commerce platform. Implement secure session cookies (HttpOnly, Secure, SameSite), enforce session timeouts, and regenerate session IDs after authentication.
4. API Security for Headless Commerce
Headless commerce architectures, where the front end is decoupled from the back end via APIs, introduce additional security considerations. Every API endpoint that handles order data, customer data, or interacts with payment services must be authenticated, rate-limited, and validated against injection attacks. API keys and tokens must be rotated regularly and never exposed in client-side code. Requirement 6.3 and 6.5 apply to all custom API development.
5. Supply Chain and Plugin Vulnerabilities
E-commerce platforms like Magento, WooCommerce, and Shopify rely on ecosystems of plugins and extensions. Compromised plugins have been one of the most common vectors for payment page compromises. Every third-party plugin that runs on your payment pages is in scope. Requirement 6.3.2 requires maintaining an inventory of all custom and third-party software components and monitoring for vulnerabilities via industry sources such as CVE databases and vendor advisories.
SAQ A vs SAQ A-EP: Decision Guide
The distinction between SAQ A and SAQ A-EP is critical for e-commerce merchants. The wrong selection can leave you non-compliant or over-investing in controls:
| Criteria | SAQ A | SAQ A-EP |
|---|---|---|
| Payment page served from | Provider's domain (redirect/iframe) | Your domain |
| Card data enters your page | No | Yes (client-side only) |
| Your scripts access card fields | No | Yes (before tokenisation) |
| Number of requirements | ~22 | ~139 |
| ASV scanning required | No | Yes (quarterly) |
| Penetration testing required | No | Yes (annually) |
| Script management (6.4.3) | Yes (new in 4.0) | Yes |
Common Pitfalls
- !Loading Google Analytics, Facebook Pixel, or chat widgets on the payment page without script inventory or SRI hashes
- !Assuming SAQ A means "no requirements" — even SAQ A now includes script management under PCI DSS 4.0
- !Storing card data in server logs or application error logs during failed transactions
- !Exposing API keys for payment gateways in client-side JavaScript bundles
- !Using outdated e-commerce platform versions with known CVEs in payment modules
- !Not implementing Content Security Policy (CSP) headers on payment pages
- !Failing to monitor payment page DOM for unauthorised modifications between deployments
- !Sharing a single SSL certificate private key across production and staging environments
Implementation Checklist
- 1Map your payment data flow from customer browser through to processor and identify every system that touches card data
- 2Select the payment architecture model (redirect, iframe, client-side tokenisation, or direct) that matches your business requirements and risk appetite
- 3Create a complete inventory of all JavaScript files loaded on payment pages with business justification for each
- 4Implement Subresource Integrity (SRI) hashes for all external scripts and Content Security Policy (CSP) headers
- 5Deploy a payment page change-detection mechanism (Requirement 11.6.1) that alerts on unauthorised modifications
- 6Configure secure HTTP headers: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- 7Implement quarterly ASV scanning for all internet-facing e-commerce infrastructure
- 8Conduct annual penetration testing of web applications and payment flows (if SAQ A-EP or D)
- 9Review and harden session management: HttpOnly cookies, secure flag, SameSite attribute, session timeouts
- 10Audit all third-party plugins and extensions for known vulnerabilities and remove unused ones
- 11Establish a process for reviewing and approving any new scripts or plugins before they reach the payment page
- 12Document your SAQ selection rationale with supporting architecture diagrams for your QSA or ISA review
Quick Facts
- Industry
- E-Commerce / Online Retail
- Primary SAQs
- SAQ A, SAQ A-EP, or SAQ D
- Top Threat
- Magecart / JavaScript skimming
- Key 4.0 Reqs
- 6.4.3 (scripts), 11.6.1 (monitoring)
Key Statistics
65%
of online merchants load 15+ third-party scripts on payment pages
18,000+
websites compromised by Magecart attacks since 2018
SAQ A
reduces requirements from 300+ to just 22 with proper architecture
7 days
maximum interval for payment page change detection (Req 11.6.1)
Get Started with GRCTrack
Automate your e-commerce PCI DSS compliance. Script inventory, SAQ selection guidance, and continuous monitoring built for online merchants.