PCI DSS Compliance for eCommerce: Payment Security Guide

Every eCommerce transaction that involves a payment card creates a compliance obligation under PCI DSS — the Payment Card Industry Data Security Standard. Non-compliance is not theoretical risk: card brands (Visa, Mastercard, Amex) can levy fines of $5,000–$100,000 per month on acquiring banks, who pass the liability directly to merchants through their payment processing agreements. Following a breach, non-compliant merchants face fines of $50–$90 per card compromised, card brand forensic investigation costs, and — in the most serious cases — termination of their merchant account.

PCI DSS v4.0, released March 2022 with mandatory compliance from March 2025, introduced significant changes to cryptographic requirements, authentication standards, and the handling of scripts on payment pages. This guide gives eCommerce teams a complete implementation roadmap.

Key Takeaways

• PCI DSS v4.0 is mandatory as of March 31, 2025 — all eCommerce merchants must be compliant with the new version
• Scoping is the most critical first step: reduce your cardholder data environment (CDE) as much as possible
• Using a payment processor's hosted payment page (Stripe, Braintree, Adyen) dramatically reduces scope
• SAQ A applies to most hosted-payment-page merchants — but only if no cardholder data touches your servers
• New v4.0 requirements include MFA for all CDE access, script integrity controls on payment pages, and targeted risk analysis
• Web skimming (Magecart attacks) is addressed by new Requirement 6.4.3 on payment page script inventory
• Annual penetration tests and quarterly vulnerability scans remain mandatory
• Non-compliance penalties are passed from card brands → acquiring banks → merchants

---

PCI DSS Framework Fundamentals

PCI DSS is maintained by the Payment Card Industry Security Standards Council (PCI SSC), a body founded by American Express, Discover, JCB, Mastercard, and Visa. The current standard is PCI DSS v4.0.

The standard is organised into 12 requirements across 6 goals:

Compliance applies to any entity that stores, processes, or transmits cardholder data — or could affect the security of cardholder data. This includes merchants, payment processors, acquirers, issuers, and service providers.

---

Step 1 — Define and Reduce Your Scope

The cardholder data environment (CDE) is any system that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). Minimising scope is the single most impactful step you can take.

Cardholder data vs. sensitive authentication data:

Scope reduction strategies for eCommerce:

1. Use a hosted payment page: Redirect customers to your payment processor's hosted payment page (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in). No cardholder data touches your servers, and you qualify for SAQ A — the simplest self-assessment questionnaire.

2. Tokenisation: Replace card numbers with processor-generated tokens immediately after authorisation. Store only the token, which is useless to attackers without access to the processor's tokenisation vault.

3. iFrame-based payment forms: Embed the payment processor's JavaScript-rendered form within your checkout page. Card data is entered directly into a form hosted on the processor's domain, not yours.

4. Network segmentation: Isolate CDE systems (payment processing servers, databases) from out-of-scope systems using firewalls. Properly segmented networks dramatically reduce audit scope.

---

Step 2 — Identify Your SAQ Type

The Self-Assessment Questionnaire (SAQ) is a validation tool for merchants and service providers that do not require a Qualified Security Assessor (QSA) on-site assessment. SAQ type is determined by how you accept payments:

SAQ A — Applicable to card-not-present (e-commerce) merchants who fully outsource payment processing to a PCI DSS-compliant third party. No electronic cardholder data is stored, processed, or transmitted on your systems or premises. Your payment page is delivered entirely by your payment processor. Approximately 22 requirements.

SAQ A-EP — For e-commerce merchants who partially outsource payment processing but still have a payment page hosted on their own server, which embeds a third-party payment iframe. Your web server indirectly affects the security of payment processing. More requirements than SAQ A. Critically affected by the new v4.0 Requirement 6.4.3.

SAQ D — For merchants who do not meet the criteria for any other SAQ type, or who store cardholder data. Covers all 12 requirements. Required for merchants running their own payment processing infrastructure. Typically ~300+ sub-requirements.

Level tiers (Mastercard/Visa standard):

---

Step 3 — PCI DSS v4.0 Key Changes for eCommerce

PCI DSS v4.0 introduced several requirements that specifically impact eCommerce merchants. All were mandatory from March 31, 2025.

Requirement 6.4.3 — Payment page script management

This requirement directly targets Magecart/web skimming attacks — where attackers inject malicious JavaScript into eCommerce payment pages to steal cardholder data in real time. Under 6.4.3, merchants using SAQ A-EP or higher must:

• Maintain an inventory of all scripts authorised to execute on payment pages
• Justify the business or technical necessity of each script
• Implement a method to confirm integrity of each script (Subresource Integrity hashes for third-party scripts, or Content Security Policy directives)

For SAQ A merchants with a fully outsourced payment page, this requirement applies to your payment processor's pages — they must demonstrate compliance on your behalf.

Requirement 11.6.1 — Change and tamper detection for payment pages

Merchants must deploy a mechanism (e.g., Content Security Policy, script monitoring service) to detect unauthorised modifications to HTTP headers and script contents on payment pages. Alerts must be generated within 7 days of any unapproved changes.

Requirement 8.4.2 — MFA for all access to the CDE

Multi-factor authentication is now required for all user accounts with access to the CDE — not just remote access. This includes internal users accessing production payment systems from within the corporate network.

Requirement 3.3.1.1 — SAD cannot be retained after authorisation

Explicitly bans storing sensitive authentication data (full track data, CVV, PIN) after authorisation. This was always prohibited but is now more precisely worded to close loopholes in how some systems logged SAD in debug/diagnostic outputs.

Targeted Risk Analysis (TRA)

v4.0 introduces the concept of Targeted Risk Analysis — merchants can demonstrate alternative approaches to some requirements if they perform a documented risk analysis showing equivalent protection. This provides flexibility for larger, more complex environments.

---

Step 4 — Network Security Architecture

For merchants with systems in scope beyond SAQ A, network security is a core compliance domain.

Requirement 1 — Install and maintain network security controls:

• Implement a firewall between untrusted networks (internet) and the CDE
• Implement a firewall between CDE and other internal networks (segmentation)
• Document all firewall rules with business justification
• Review firewall rules at least every 6 months
• Deny all traffic not explicitly required (default-deny posture)
• For eCommerce: implement WAF (Web Application Firewall) in front of web servers

Network segmentation testing:

A common misconception is that network segmentation reduces scope automatically. PCI SSC requires you to test that segmentation is effective — penetration tests must include attempts to cross the segmentation boundary. If a penetration tester can reach CDE systems from out-of-scope networks, segmentation is not effective and the broader environment comes into scope.

DMZ architecture for eCommerce:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

Web servers in the DMZ serve your storefront. Only specific, documented traffic (HTTPS to payment API, SQL on specific port to specific DB) crosses from DMZ to CDE. All other traffic is blocked.

---

Step 5 — Application Security Requirements

Requirement 6 — Develop and maintain secure systems and software:

• Maintain an inventory of all custom and third-party software in scope
• Address vulnerabilities as part of a formal vulnerability management process
• Protect web-facing applications against known attacks (OWASP Top 10)
• Conduct security code reviews or application penetration tests before production deployment of significant changes
• Use only software from reputable vendors with committed security patch processes

Web application firewall (WAF) — Requirement 6.3.2 and 6.4.2:

WAF is mandatory for all public-facing web applications, configured to either block attacks or generate alerts and review within 1 hour. For eCommerce, WAF must cover:

• SQL injection prevention
• Cross-site scripting (XSS) protection
• Cross-site request forgery (CSRF) protection
• Malicious bot detection
• Rate limiting for brute force prevention

Dependency and third-party software management:

eCommerce platforms (WooCommerce, Magento, Shopify customisations) rely heavily on plugins and extensions. Each plugin in scope must be assessed for security. Maintain an inventory and apply patches within your patching SLA (critical: 7 days from vendor patch release).

---

Step 6 — Access Control and Authentication

Requirement 7 — Restrict access to system components and cardholder data:

• Implement role-based access control based on least privilege
• Default all access to "deny all" with explicit grants documented
• Review user access rights at least every 6 months

Requirement 8 — Identify users and authenticate access:

• Assign a unique ID to each person with access to the CDE
• Passwords minimum 12 characters (v4.0 increase from 7 in v3.2.1), complexity requirements
• Lock accounts after maximum 10 invalid attempts (v4.0 default, or per TRA)
• Session timeout after maximum 15 minutes inactivity for CDE sessions
• MFA required for all CDE access (v4.0 expansion from remote-only)
• Service accounts and system accounts must be managed separately from user accounts

---

Step 7 — Vulnerability Management and Testing

Requirement 11 — Test security of systems and networks:

Quarterly internal vulnerability scans: Scan all in-scope systems. Remediate all high-severity and critical vulnerabilities before next scan. Scans can be conducted by internal staff using approved tools (Nessus, Qualys, OpenVAS).

Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV): External scans of all externally accessible systems must be conducted by a PCI SSC-approved ASV. The scan must pass (no open high/critical vulnerabilities) before you can attest compliance.

Annual penetration testing: Conducted by a qualified internal resource or reputable external firm. Must cover:

• All in-scope systems and networks
• Segmentation controls (verify that CDE is properly isolated)
• OWASP Top 10 for web-facing applications
• Social engineering (for higher-risk environments)

Remediate all penetration test findings and conduct verification testing to confirm remediation.

File Integrity Monitoring (FIM): Deploy FIM on all critical system files, configuration files, and content files. Alert within 1 hour (v4.0) of any unauthorised changes.

---

PCI DSS Compliance Checklist for eCommerce

• Payment processing scope defined and reduced (hosted payment page or tokenisation used where possible)
• SAQ type identified based on payment acceptance method
• Network segmentation implemented and documented
• Cardholder data inventory completed — no SAD stored anywhere
• All cardholder data storage encrypted (AES-256 or equivalent)
• TLS 1.2+ enforced for all payment data transmission
• Payment page script inventory documented (Requirement 6.4.3)
• Change/tamper detection deployed on payment pages (Requirement 11.6.1)
• WAF deployed in front of all public-facing web applications
• MFA enforced for all CDE access (Requirement 8.4.2)
• Unique user IDs, strong passwords, account lockout configured
• Quarterly vulnerability scans (internal + ASV external) completed
• Annual penetration test completed, findings remediated
• File integrity monitoring deployed on CDE systems
• Firewall rules reviewed within last 6 months
• Security awareness training completed for all CDE-touching staff
• Incident response plan covers payment card breach scenarios
• Vendor/service provider PCI DSS compliance verified

---

Frequently Asked Questions

We use Shopify for our store — do we still need PCI DSS compliance?

Shopify is a PCI DSS Level 1 certified service provider. If you use Shopify's standard payment processing (Shopify Payments or Shopify-hosted checkout), your compliance scope is dramatically reduced. You still have obligations — primarily SAQ A — covering your use of Shopify's services. If you add custom JavaScript to your Shopify checkout or use third-party payment apps that process card data outside Shopify's environment, scope expands.

What is the difference between PCI DSS compliance and PCI DSS certification?

There is no formal "PCI DSS certification" for merchants. Merchants attest compliance via Self-Assessment Questionnaires or (Level 1 merchants) via a Report on Compliance (RoC) conducted by a QSA. Service providers can be listed on Visa's Global Registry of Service Providers. The terms "certified" and "compliant" are often used interchangeably in market communications, but technically merchants self-attest or have QSA-attested compliance.

What penalties do merchants face for non-compliance?

Penalties are not directly from PCI SSC — they flow from card brands through acquiring banks. Monthly fines typically range $5,000–$100,000 depending on merchant level and duration of non-compliance. Following a breach, card brands may impose per-card fines ($50–$90 per Visa card, similar for Mastercard), forensic investigation costs ($20,000–$200,000+), and mandatory card reissuance costs. In severe cases, merchants lose their ability to accept card payments entirely. Repeat offenders or merchants with large breach impacts face the highest penalties.

What is a Magecart attack and how does PCI DSS v4.0 address it?

Magecart refers to attacks where malicious JavaScript is injected into eCommerce checkout pages to intercept cardholder data in real time as customers type it. These attacks exploit third-party scripts (analytics, chat widgets, tag managers) that merchants include on payment pages. PCI DSS v4.0 Requirements 6.4.3 and 11.6.1 directly address this: merchants must inventory and verify the integrity of all scripts on payment pages, and deploy monitoring to detect unauthorised changes to payment page code.

How do we handle PCI DSS for a headless eCommerce architecture?

Headless eCommerce separates the frontend presentation layer from the backend commerce engine. For PCI DSS purposes, what matters is where cardholder data flows. If your headless frontend uses Stripe Elements or a similar iFrame-based solution, card data goes directly from the browser to the payment processor without touching your frontend servers — this is SAQ A territory. If your headless architecture involves custom server-side payment processing, scope expands significantly and you should engage a QSA for scoping guidance.

Do we need a QSA for our PCI DSS assessment?

Only Level 1 merchants (over 6 million transactions/year for Visa/Mastercard) are required to engage a QSA for an annual Report on Compliance (RoC). Level 2–4 merchants can self-attest via SAQ. However, many merchants voluntarily engage a QSA or Qualified Security Assessor Company (QSAC) for guidance even when not required, particularly when they are unsure of their scoping or have complex infrastructure.

---

Next Steps

PCI DSS compliance protects your customers' payment data, limits your liability exposure, and is a prerequisite for maintaining card acceptance. For eCommerce businesses on Shopify or custom platforms, the first step is always scope reduction — getting to SAQ A through proper use of hosted payment pages is the fastest and most cost-effective path.

ECOSIRE's eCommerce implementation team has extensive experience building PCI DSS-compliant Shopify stores and custom commerce platforms, with payment architecture designed from the ground up to minimise CDE scope.

Get started: ECOSIRE Shopify Services

Disclaimer: This guide is for informational purposes only and does not constitute legal or compliance advice. PCI DSS requirements may change and vary by card brand and acquirer. Engage a QSA for definitive compliance guidance specific to your environment.