E-commerce introduces PCI DSS challenges that brick-and-mortar merchants do not face. Your payment page is accessible to anyone on the internet. Third-party JavaScript runs on pages where customers enter card data. Payment integrations range from simple redirects to complex client-side tokenization flows, and each model carries different compliance obligations.
PCI DSS v4.0 added requirements specifically targeting e-commerce threats, most notably Requirement 6.4.3 for payment page script management. If you run an online store, these changes directly affect your compliance posture and your SAQ type.
Payment Page Architecture and SAQ Impact
| Integration Type | How It Works | SAQ Type |
|---|---|---|
| Full redirect | Customer leaves your site entirely, enters card data on processor's domain (e.g., Stripe Checkout, PayPal Standard) | SAQ A (22 requirements) |
| Iframe embed | Payment form rendered in an iframe from the processor, embedded on your page. Your page serves JavaScript but card data goes directly to processor | SAQ A-EP (191 requirements) |
| JavaScript SDK | Payment fields rendered by processor's JavaScript SDK on your page (e.g., Stripe Elements, Braintree Hosted Fields). Card data tokenized client-side | SAQ A-EP (191 requirements) |
| Direct post | Card data entered on your form, posted directly to processor API from the browser. Your server never sees the PAN | SAQ A-EP (191 requirements) |
| Server-side processing | Card data submitted to your server, then forwarded to processor via server-side API call. Your server handles the PAN | SAQ D (326 requirements) |
JavaScript Skimming and Magecart
Magecart attacks are the defining e-commerce security threat. Attackers inject malicious JavaScript into payment pages that captures card data as customers type it, then exfiltrates the data to attacker-controlled servers. The attack happens entirely in the customer's browser, bypassing server-side security controls.
Attack vectors include compromised third-party scripts (analytics, chat widgets, A/B testing tools), supply chain attacks on JavaScript CDNs, compromised CMS plugins, cross-site scripting vulnerabilities, and compromised developer accounts. A single compromised script on your payment page can capture every card number entered.
Why this matters for SAQ A merchants: Even if you use a full redirect checkout and qualify for SAQ A, a Magecart-style attack on your product pages could redirect customers to a fake payment page before they reach the legitimate checkout. The threat extends beyond just the payment page itself.
Requirement 6.4.3: Payment Page Script Management
PCI DSS v4.0 added Requirement 6.4.3 specifically to combat JavaScript skimming. This requirement mandates that all payment page scripts are managed with the following controls:
- Script inventory. Maintain a list of all scripts loaded and executed on payment pages, including third-party scripts. Each script must have a documented business justification
- Authorization. Each script must be explicitly authorized. Unauthorized scripts must be blocked or removed
- Integrity verification. Implement a mechanism to detect unauthorized changes to scripts. This can be Content Security Policy (CSP), Subresource Integrity (SRI) hashes, or a real-time monitoring solution
Implementation approaches
Content Security Policy (CSP) is the most common approach. A properly configured CSP header restricts which domains can serve JavaScript on your payment pages. Any script from an unauthorized domain is blocked by the browser. CSP with script-src directives is the foundation, but it requires ongoing maintenance as legitimate scripts are added or CDN domains change.
Subresource Integrity (SRI) adds hash verification to external scripts. The browser verifies that the script content matches the expected hash before executing it. If an attacker modifies the script on the CDN, the hash will not match and the browser will refuse to execute it. SRI works well for stable scripts but requires hash updates whenever the script vendor publishes an update.
Tokenization for E-Commerce
Tokenization is the most effective scope reduction strategy for e-commerce. Instead of storing PANs, store tokens issued by your payment processor. Tokens can be used for recurring billing, refunds, and customer account management without your systems ever handling the actual card number.
Most modern payment processors provide tokenization as part of their standard integration. Stripe, Braintree, Adyen, and others return tokens when a payment method is created. Store the token, not the card number. Use the token for subsequent charges. Your systems never need to see the PAN after the initial tokenization, which happens in the customer's browser via the JavaScript SDK.
Common E-Commerce PCI Failures
- Third-party scripts on payment pages. Analytics, chat widgets, retargeting pixels, and social media buttons loading on the checkout page. Each one is a potential attack vector and must be inventoried per Requirement 6.4.3
- Wrong SAQ type. Merchants claiming SAQ A when they embed payment forms via JavaScript SDK on their domain. The correct SAQ is A-EP, which has 191 requirements instead of 22
- No CSP on payment pages. Payment pages without Content Security Policy headers allow any script from any domain to execute, making Magecart injection trivial
- Logging card data. Application logs, error logs, or debugging output that captures full PANs. Log aggregation services that ingest and store this data compound the violation
- Test card data in production. Development or testing processes that use real card numbers in non-production environments. Test environments that receive real card data are in PCI DSS scope
Need e-commerce security testing?
We test e-commerce platforms for PCI DSS compliance, including payment page security, JavaScript skimming vulnerabilities, and Requirement 6.4.3 validation.
