PCI DSS 4.0 for Online Shops: Compliance Rules 2026

Since 1 April 2025 every one of the 64 new requirements in PCI DSS 4.x is mandatory in any assessment, and the legacy v3.2.1 was retired in March 2024 (PCI SSC). For every German online shop accepting card payments — even through an iframe or redirect — script management, MFA and continuous audit-log review are now baseline duties. At the same time the threat landscape has hardened: Magecart attacks climbed 103 % within six months of 2024/2025 (LevelBlue/SpiderLabs), and in a German e-commerce market worth EUR 80.6 billion annually (BEVH) card data is one of the most rewarding targets. This guide explains what has changed, where the typical compliance gaps sit and how we at XICTRON harden shops for PCI DSS 4.0.

Why PCI DSS 4.0 matters for every online shop

PCI DSS applies to every organisation that processes, transmits or stores cardholder data, regardless of size or transaction volume. The standard is maintained by the major card brands and enforced through acquirer contracts. Even a shop that "only" embeds a hosted iframe of a Payment Service Provider remains accountable. The changes introduced in v4.x make sure that the Cardholder Data Environment (CDE) is protected on a technical as well as an organisational level. Ignoring compliance creates exposure to fines and, in the case of a breach, higher liability.

The threat landscape already demands action. The IBM Cost of a Data Breach Report 2025 puts the global average breach cost at USD 4.44 million (IBM). In Germany, with an e-commerce market of EUR 80.6 billion (BEVH), card data is a rewarding target. The Bitkom Wirtschaftsschutz 2024 report puts the yearly damage from cybercrime in Germany at EUR 178.6 billion (Bitkom), 81 % of German companies have been hit by data theft or sabotage in the last 12 months, and 65 % consider cyberattacks an existential risk (Bitkom).

• 311 billion web attacks were recorded worldwide in 2024, up 33 % year over year (Akamai State of the Internet 2025)
• More than 230 billion of them targeted commerce organisations (Akamai)
• 150 billion API attacks between January 2023 and December 2024; OWASP API incidents up 32 % (Akamai)
• PCI non-compliance fines range from USD 5,000 to 100,000 per month, depending on merchant level (NordLayer)
• On top of that USD 50 to 90 per compromised record (Secureframe)
• The BSI Situation Report 2025 records 24 % more new vulnerabilities per day; SMEs account for 80 % of ransomware cases (BSI)

What changed fundamentally after March 2025

PCI DSS 4.0 was published in March 2022. The predecessor v3.2.1 was officially retired on 31 March 2024 (PCI SSC). At the same time 13 new requirements became immediately mandatory, while 51 further items were marked as "future-dated" and had to be in place by 31 March 2025 (PCI SSC). Since 1 April 2025 every one of the 64 changes is binding in any assessment (CompliancePoint). A limited revision to v4.0.1 followed on 11 June 2024, clarifying several points including script management (PCI SSC).

The consequence: many merchants who could rely on a simplified SAQ A in 2023 must in 2026 evidence the full catalogue. Script integrity, MFA, audit logging and penetration testing are especially affected — none of which can be patched together on a short timeline. If you start now, you are already under pressure. For the broader security mindset, see our Zero-Trust guide for online shops.

Magecart and web skimming: the acute threat

Magecart refers to a loose group of actors who inject JavaScript into checkout pages and siphon card data directly from the customer's browser, invisible to the shop backend and traditional firewalls. The attacks rarely target the shop software itself; instead, they piggyback on third-party scripts loaded inside the payment page. In 2024 alone, 11,000 unique e-commerce domains were hit by eSkimming campaigns, a 300 % increase year over year (Source Defense). In the same year, 269 million cards were compromised client-side (Source Defense).

A particularly painful 2024 vulnerability was CosmicSting (CVE-2024-34102), affecting roughly 75 % of all Adobe Commerce and Magento installs (Sucuri/LevelBlue). The Verizon DBIR 2024 attributes 18 % of all retail breaches to Magecart-style attacks (Verizon). Telemetry from LevelBlue/SpiderLabs shows that the attack wave in 2024/2025 more than doubled within six months — a 103 % increase (LevelBlue/SpiderLabs).

Script management under 6.4.3 and 11.6.1

Requirements 6.4.3 and 11.6.1 are the heart of the v4.x changes for shop operators. They demand three things: a complete inventory of every script loaded on payment pages, documented authorisation for each script with a justification of its necessity, and an integrity check through tamper detection at least weekly (PCI SSC/Akamai). In practice this means that every external or indirectly loaded script must be known, documented and monitored.

The scale is routinely underestimated. Average web pages now load 18 scripts, a 50 % increase over two years, and 40 % of all scripts are executed on payment pages (Source Defense). Roughly half of the JavaScript in e-commerce comes from third parties (Akamai). Yet only 36 % of organisations have any tooling against data skimming in place (Jscrambler).

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.psp-example.com 'sha384-4g5z...';
  connect-src 'self' https://api.psp-example.com;
  frame-src https://checkout.psp-example.com;
  report-uri /csp-report-endpoint;

<!-- Subresource Integrity for statically included scripts -->
<script
  src="https://js.psp-example.com/v1/widget.js"
  integrity="sha384-4g5z.../abc123=="
  crossorigin="anonymous"></script>

CSP and Subresource Integrity are just building blocks. You also need server-side rendering where possible, a script inventory tied into change management, and monitoring that logs and alerts on hash deviations. Operators of a platform such as Shopware should couple theme updates and plugin rollouts to a mandatory script audit.

MFA and authentication tightened

Password requirements have been noticeably tightened in v4.x. Requirement 8.3.6 now mandates at least 12 alphanumeric characters (up from 7). Even more important is Requirement 8.4.2: since 31 March 2025, multi-factor authentication is required for every non-console access inside the CDE, not just for administrative accounts (Schellman). This affects every shop employee who connects remotely to servers, databases or admin consoles where card data could become visible.

The Verizon DBIR 2025 explains why this matters: 88 % of all basic web application attacks rely on stolen credentials (Verizon). A second factor — ideally a hardware key or a phishing-resistant authenticator — devalues the stolen login. If you still rely on SMS codes, plan a migration to TOTP or FIDO2 schemes soon. In our consulting projects we always run a role audit as part of the exercise: who really needs CDE access, and who can be served through a scoped admin panel?

Vulnerability scans and penetration testing on a quarterly cycle

PCI DSS 4.x requires quarterly external ASV scans conducted by an Approved Scanning Vendor. Every vulnerability with a CVSS score of 4.0 or higher must be remediated and documented with a clean scan within the scan window (PCI SSC). In addition, authenticated internal scans (Req. 11.3.1.2) are required quarterly (CompliancePoint). Penetration tests are mandatory annually and after significant changes. New since 31 March 2025: multi-tenant service providers (hosting and cloud) must actively support their customers in external pen-testing — Requirement 11.4.7 (KirkpatrickPrice). For shop operators this means the host has to provide staging environments, access paths and a coordination contact so pen-testers can work legally and safely on production. Teams that maintain custom code in the checkout benefit additionally from accompanying custom development that builds security reviews into every release pipeline.

Tokenisation as a scope reducer

The single most effective way to shrink the PCI footprint remains tokenisation: instead of the actual Primary Account Number (PAN), the shop processes and stores only a token issued by the PSP. Cybersource reports that compliance effort can be reduced by up to 90 % this way (Cybersource). Network tokens go a step further: they are issued directly by the card network and automatically updated when cards are lost or expire, improving authorisation rates by 2 to 3 percentage points according to ACI Worldwide (ACI Worldwide).

For most German SMEs the path is clear: replace PAN with tokens as early as possible, move the checkout into a hosted iframe or redirect page at the PSP, and keep only tokens inside the shop backend. Shops that integrate wallets and new European A2A methods such as Wero decouple themselves from classic card risks. And express checkout flows naturally benefit from tokenised payment methods.

SAQ A vs. A-EP vs. D — which questionnaire for which shop?

Self-Assessment Questionnaires (SAQs) are the practical compliance vehicle for merchants at levels 2 to 4. Picking the right SAQ determines cost and effort. SAQ A applies to shops that fully outsource the payment process to a PCI-certified provider (iframe or redirect). SAQ A-EP covers shops that never touch PAN but whose servers influence the payment flow (for example through custom checkout logic). SAQ D is the full version for merchants that process or store card data themselves.

Understanding cloud shared responsibility

If you run your shop in the cloud, you share PCI responsibility with the cloud provider. AWS publishes a PCI DSS Responsibility Matrix that explicitly lists which controls AWS owns and which stay with the customer — data, OS patches and firewall configuration are typically on the customer side (AWS Whitepaper). Microsoft Azure publishes its own matrix, differentiated by service type (Microsoft Learn). The key message for operators: actively map your own share and never assume that a certified platform covers every control automatically.

If you prefer a German-based host, insist on an explicit PCI responsibility matrix and on evidence for the data centre's certifications. For our shop customers we provide a documented split of responsibilities and logging and patch workflows that follow the PCI baseline — without offering our own QSA status.

Reaching compliance in seven steps

The road to PCI DSS 4.0 can be structured pragmatically. The following sequence has proven itself in our consulting engagements and avoids expensive detours.

1. Define the scope: identify every system, network, script and service provider that touches or influences card data. Produce a diagram with all data flows.
2. Gap analysis: map the current state against the 64 new items in v4.x and produce a prioritised gap list with owners.
3. Reduce the scope: tokenise card data, move checkout into a hosted PSP flow, pull admin zones out of the CDE — the most effective measure before any technical hardening.
4. Build a script inventory: log every line of JavaScript on payment pages, enable CSP and SRI, deploy tamper-detection monitoring (Req. 6.4.3 / 11.6.1).
5. Harden technical controls: MFA 8.4.2 everywhere, password policy 8.3.6 at 12 characters, automated log review 10.4.1.1.
6. Scans and testing: quarterly ASV scans, authenticated internal scans, annual pen-tests — all with documented reports and remediation evidence.
7. Continuous monitoring: retain audit logs for 12 months (3 months immediately retrievable), detect and remediate security control failures according to 10.7.2.

How XICTRON hardens your shop security

We guide shop operators through PCI DSS 4.0 along the full stack — from hosting through scope reduction by tokenisation and clean script management for Shopware and WooCommerce checkouts, to MFA rollouts and automated log review running in our cloud setups. We do not provide QSA certification; instead we deliver the technical and organisational foundation on which your QSA can later assess. The best starting point is a structured gap assessment.