E-Commerce Guide

PCI Compliance for E-Commerce — Protect Customers, Avoid Fines

If you sell online and accept card payments, PCI DSS applies to you. But the scope of your compliance obligation varies enormously depending on how you integrate with your payment provider. This guide covers every scenario — from fully outsourced redirects to server-side processing — and shows you how to minimise scope while maximising security.

Payment Integration Types

The way you integrate payments into your e-commerce site is the single biggest factor in determining your PCI DSS compliance scope. Each integration type carries different risks and maps to a different SAQ. Understanding these distinctions is essential before you begin any compliance work.

Redirect (Full Outsource)

With a redirect integration, the customer is sent to your payment provider's website to enter their card details. Your website never touches cardholder data — not even transiently. Examples include Stripe Checkout (redirect mode), PayPal Standard, and Adyen's hosted payment page. This is the lowest-scope option and qualifies for SAQ A (approximately 22 controls).

The key requirement is that the redirect must take the customer to a completely separate domain controlled by your payment provider. Your site's HTML does not contain any payment form elements. After payment, the customer is redirected back to your confirmation page.

Iframe (Embedded Payment Form)

An iframe integration embeds a payment form from your provider inside your website using an HTML <iframe>. The payment form is served from the provider's domain, but it appears visually as part of your checkout page. Examples include Stripe Elements and Braintree Drop-in UI. This also qualifies for SAQ A, but your payment page must still be protected against tampering — a critical point under PCI DSS v4.0.1.

Tokenisation (Client-Side)

With client-side tokenisation, JavaScript from your payment provider runs in the customer's browser to collect card details and exchange them for a token. The token is then sent to your server. Your server never receives the actual card number — only the token. Examples include Stripe.js with Elements and Square Web Payments SDK. Because your payment page loads the provider's JavaScript, this typically qualifies for SAQ A if structured correctly, but the JavaScript must be carefully managed per Requirement 6.4.3.

Direct Post

In a direct post integration, your website hosts the payment form HTML but the form's action URL points directly to your payment provider's servers. The card data is entered on your page but posted directly to the provider without touching your server. This is a more complex scenario that typically requires SAQ A-EP (approximately 139 controls) because your page controls the HTML form that collects cardholder data, even though the data bypasses your server.

Server-Side Processing

Server-side processing means your web server receives cardholder data directly, whether through a server-to-server API call, a form post to your own backend, or any other method where your infrastructure handles raw card numbers. This is the highest-scope scenario and requires SAQ D (300+ controls) or a full ROC assessment. Unless you have a specific business requirement, you should avoid server-side processing and use one of the lower-scope integration methods instead.

SAQ Selection for E-Commerce

Choosing the correct SAQ is critical. An incorrect SAQ means you are either over-investing in compliance for a simpler environment or, worse, under-reporting your actual risk. Use this decision tree to determine your SAQ type:

Not sure which integration type you are using? The SAQ Decision Engine walks you through a series of questions to determine your exact SAQ type in under two minutes.

Securing Your Payment Page

PCI DSS v4.0.1 introduced two requirements that fundamentally changed payment page security for e-commerce: Requirement 6.4.3 (payment page script management) and Requirement 11.6.1 (payment page tamper detection). These became mandatory on March 31, 2025, and are now one of the most common areas of non-compliance for e-commerce merchants.

Content Security Policy (CSP) Headers

A Content Security Policy header tells the browser which domains are allowed to load scripts, styles, frames, and other resources on your payment page. Implementing a strict CSP is one of the most effective ways to prevent script injection attacks. For a payment page, your CSP should restrict script-src to only your domain and your payment provider's domain. Avoid unsafe-inline and unsafe-eval directives on payment pages.

Example CSP for a Stripe integration: Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com; style-src 'self' 'unsafe-inline';

Subresource Integrity (SRI)

SRI allows you to ensure that scripts loaded from third-party CDNs have not been modified. By adding an integrity attribute to your <script> tags, the browser will verify the file's hash before execution. If the hash does not match (indicating the file was tampered with), the browser blocks execution. SRI is most effective for scripts you load from CDNs that change infrequently. For dynamically loaded payment provider scripts, SRI may not be practical — use CSP restrictions instead.

Script Monitoring (Requirement 6.4.3)

Requirement 6.4.3 mandates that all scripts on payment pages must be managed through a process that includes: authorising each script, ensuring script integrity, and maintaining an inventory of all scripts with written justification for each. You must also have a mechanism to detect and alert on unauthorised script changes. This can be accomplished through:

• CSP with report-uri — Configure CSP to report policy violations to a monitoring endpoint, alerting you when unauthorised scripts attempt to load.
• Real-time script monitoring — Services that continuously scan your payment pages for new or modified scripts and alert on changes.
• File integrity monitoring — Monitor your payment page source files for changes, alerting when any script reference is added or modified.
• Automated testing — Regular automated checks that compare current page scripts against your authorised inventory.

For detailed implementation guidance on Requirement 6.4.3, see the implementation guides and explore how the PCI DSS v4.0.1 migration guide covers this requirement in context.

Tokenisation and Scope Reduction

Tokenisation is the process of replacing a Primary Account Number (PAN) with a non-sensitive substitute value called a token. The token has no exploitable value if breached and cannot be reversed into a card number without access to the tokenisation system. For e-commerce merchants, tokenisation is one of the most powerful scope reduction strategies available.

How Tokenisation Works

When a customer enters their card number on your payment page, your payment provider (Stripe, Braintree, Adyen, etc.) captures the card data and returns a token. Your server stores the token — not the card number — for future transactions like recurring billing, refunds, or one-click purchases. The token is only meaningful within the context of your payment provider; it cannot be used to process payments elsewhere.

Impact on PCI Scope

When tokenisation is implemented correctly, your systems never store, process, or transmit actual cardholder data. The token is not considered cardholder data under PCI DSS, so systems that only handle tokens are outside PCI scope. This dramatically reduces the number of systems requiring compliance controls. However, the initial collection point (your payment page) is still in scope because that is where the customer enters their card details — even if the data goes directly to your payment provider via JavaScript.

Tokenisation Best Practices

• Use provider-managed tokenisation — Do not build your own tokenisation system. Use your payment provider's built-in tokenisation (Stripe tokens, Braintree nonces, etc.) which is already PCI DSS validated.
• Never log tokens alongside contextual data — While tokens are not card numbers, logging tokens with transaction amounts, dates, and customer identifiers can create patterns that assessors may flag as risk.
• Ensure token format is non-reversible — Tokens must not contain any derivable cardholder data. Format-preserving tokens that look like card numbers can create confusion about what is real data versus tokenised data.
• Document your tokenisation architecture — Include tokenisation in your data flow diagrams, showing where the real card data is handled (payment provider) and where tokens flow (your systems).

Use the CDE Scoping Tool to visualise how tokenisation reduces your cardholder data environment and the Scope Calculator to estimate the compliance cost difference between tokenised and non-tokenised environments.

3D Secure and PCI Compliance

3D Secure (3DS) is an authentication protocol that adds a verification step during online card transactions. The latest version, 3DS2, provides a frictionless authentication experience using risk-based assessment. While 3DS is important for fraud prevention, it is frequently misunderstood in the context of PCI DSS compliance.

What 3DS Does

• Shifts fraud liability — When a 3DS-authenticated transaction results in fraud, the liability typically shifts from you (the merchant) to the card issuer. This is a significant financial benefit.
• Reduces chargebacks — Authenticated transactions have significantly lower chargeback rates, which improves your standing with acquirers and card brands.
• Required in some regions — The EU's Strong Customer Authentication (SCA) requirement under PSD2 mandates 3DS or equivalent authentication for most online transactions in the EEA.

What 3DS Does Not Do

3DS does not reduce your PCI DSS scope or change your SAQ type. This is a common misconception. Whether or not you implement 3DS, your PCI requirements are determined by how you handle cardholder data. A merchant using direct post integration needs SAQ A-EP regardless of whether 3DS is enabled. The authentication protocol operates at the transaction level, not at the data handling level.

3DS also does not protect against data-in-transit interception, stored data breaches, or payment page script injection. It is an authentication mechanism, not a data protection mechanism. Continue to implement all applicable PCI DSS requirements alongside 3DS.

E-Commerce Compliance Checklist

Regardless of your SAQ type, every e-commerce merchant should complete these 10 essential compliance activities. Items marked with an asterisk (*) are new or strengthened in PCI DSS v4.0.1.

1. Determine your SAQ type

   Use the SAQ Decision Engine to identify the correct questionnaire for your payment integration. Getting this wrong means your entire assessment is built on an incorrect foundation.

2. Ensure all payment page scripts are inventoried and authorised *

   Requirement 6.4.3 mandates an authorised inventory of all scripts on payment pages with written justification for each. Implement CSP headers and script integrity monitoring.

3. Implement payment page tamper detection *

   Requirement 11.6.1 requires a mechanism to detect changes to payment page HTTP headers and content as received by the consumer browser. Deploy a monitoring solution that alerts on unexpected changes.

4. Conduct quarterly ASV vulnerability scans

   Schedule external vulnerability scans with an Approved Scanning Vendor every quarter. Address and remediate any findings rated 4.0 or higher on the CVSS scale before your next scan.

5. Enforce TLS 1.2+ on all pages

   All pages — not just payment pages — must use strong cryptography. Disable TLS 1.0 and 1.1. Configure your web server to only support TLS 1.2 and 1.3 with strong cipher suites.

6. Implement MFA for all administrative access *

   Multi-factor authentication is required for all administrative access to your e-commerce platform, hosting control panel, payment provider dashboard, and any system that can impact the security of your payment environment.

7. Review and validate your payment provider's PCI compliance

   Request your payment provider's current AOC (Attestation of Compliance) and confirm it is assessed against PCI DSS v4.0.1. Verify that their compliance covers the services you use.

8. Document your payment data flow

   Create a clear diagram showing how cardholder data flows from the customer's browser through your payment provider and back. Identify every system and network segment involved.

9. Maintain security awareness training for all staff

   All personnel with access to your e-commerce admin panel, payment dashboard, or CDE systems must complete security awareness training at hire and annually. Include phishing awareness per Req 5.4.1.

10. Submit your SAQ and AOC to your acquirer

    After completing your assessment, submit the signed SAQ and AOC to your acquiring bank by their stated deadline. Most acquirers require annual submission. Failure to submit can result in non-compliance penalties.

Generate a detailed, SAQ-specific compliance checklist with the PCI Compliance Checklist Generator.

Platform-Specific Guidance

Your e-commerce platform significantly impacts your PCI compliance posture. Here is guidance for the most common platforms, including what each handles for you and what remains your responsibility.

Shopify

Shopify is a fully hosted e-commerce platform that handles payment processing through Shopify Payments (powered by Stripe) or third-party payment gateways. Shopify is PCI DSS Level 1 certified, meaning the platform infrastructure is assessed annually by a QSA.

What Shopify handles: Payment page hosting, cardholder data processing, TLS encryption, vulnerability management, and infrastructure security. Shopify merchants using Shopify Payments typically qualify for SAQ A.

What remains your responsibility: Account security (MFA on your Shopify admin), access control for staff accounts, security awareness training, third-party app review (any app with access to your store could introduce risk), and ensuring custom theme code does not compromise payment page security. If you use Shopify's checkout customisation features that inject JavaScript into the payment flow, your SAQ type may change.

WooCommerce

WooCommerce is a self-hosted WordPress plugin, meaning you are responsible for the entire hosting environment. Your PCI scope depends entirely on which payment gateway plugin you use and how it integrates.

With Stripe for WooCommerce (redirect or iframe): Qualifies for SAQ A. Card data is collected by Stripe's JavaScript and never touches your server. However, your WordPress installation, server, and all plugins must still be maintained securely — a compromised plugin could inject scripts into your payment page.

With a direct integration gateway: May require SAQ A-EP or SAQ D depending on how the plugin handles card data. Review your gateway plugin's documentation carefully. Some older WooCommerce payment plugins collect card data in forms hosted on your domain, which increases scope significantly.

Critical WooCommerce concerns: Keep WordPress core, WooCommerce, and all plugins updated. Remove unused plugins. Use a Web Application Firewall (WAF). Implement CSP headers on checkout pages. Monitor for malicious plugin injections. The open nature of WordPress makes it a frequent target for payment page script injection attacks.

Magento (Adobe Commerce)

Magento is a powerful e-commerce platform that can be self-hosted or used as Adobe Commerce Cloud. Self-hosted Magento requires significant PCI compliance effort because you control the entire stack.

Adobe Commerce Cloud: Adobe manages the hosting infrastructure and holds its own PCI DSS compliance. This reduces your scope but does not eliminate it — you are still responsible for application-level security, access control, custom code, and extension management.

Self-hosted Magento: You are responsible for everything from server hardening to payment page security. Use Magento's built-in payment abstraction layer with a PCI-validated gateway. Magento's history of Magecart attacks makes payment page script monitoring (Req 6.4.3) especially critical. Keep all extensions updated and audit third-party extensions for security before installation.

Custom-Built E-Commerce

If you have built a custom e-commerce application, your PCI compliance responsibility is fully in your hands. The integration pattern you choose determines your SAQ type:

• Use hosted payment pages or iframes from your payment provider to qualify for SAQ A and minimise scope.
• If you must host the payment form, use client-side tokenisation with your provider's JavaScript library (SAQ A or A-EP depending on implementation).
• Never pass card data through your server unless absolutely necessary. This escalates you to SAQ D with 300+ controls.
• Implement Requirement 6.4.3 from day one — inventory all scripts, implement CSP, and monitor for unauthorised changes.
• Follow secure development practices per Requirement 6 including code review, vulnerability testing, and secure coding standards.

For custom builds, engaging a QSA early in development can prevent architectural decisions that unnecessarily increase PCI scope. It is far cheaper to design for low scope than to re-architect later.

Simplify E-Commerce PCI Compliance

GRCTrack identifies your SAQ type, generates a personalised checklist, tracks your evidence, and connects you with QSAs who understand e-commerce.

Frequently Asked Questions