PCI DSS v4.0 was released March 2022. Version 3.2.1 was retired March 31, 2024. Since that date, v4.0 is the only valid version — and v4.0 includes 64 new requirements and 51 requirements that were previously best practices but are now mandatory. Most are engineering requirements: specific controls that must be implemented in code, infrastructure, and development processes.
The Payment Card Industry's Security Standards Council structured v4.0 to allow two compliance approaches: the traditional defined approach (specific controls defined by PCI SSC) and a new customized approach (organizations define their own equivalent controls). The customized approach is more flexible but requires documented risk analysis and validation by a QSA — it is not an escape hatch from technical controls.
Requirement 6.4.3: The Script Integrity Requirement That Breaks SPAs
Requirement 6.4.3 is the new requirement that most modern payment web applications fail. It requires that all scripts loaded and executed in the consumer's browser on payment pages are managed and authorized, including: a method is implemented to confirm that each script is authorized, a method is implemented to confirm the integrity of each script, and an inventory of all scripts is maintained with written justification for each script.
For a standard React or Next.js payment page that loads scripts from CDNs (analytics, tag managers, A/B testing tools, customer support widgets), satisfying 6.4.3 requires Subresource Integrity (SRI) hashes for every third-party script, a Content Security Policy that restricts script sources, and an inventory document. The problem: many third-party scripts update frequently without versioned URLs, making SRI hashes stale. The architectural response is to self-host or proxy all third-party scripts used on payment pages, or to redesign the payment page to minimize third-party script dependencies.
Requirement 6.4.3 effectively means your payment page cannot use Google Tag Manager, most analytics platforms, or most third-party chat/support widgets without architectural changes. These services load scripts dynamically and update their script content without changing the URL. A GTM container that loads a dozen third-party tags cannot satisfy the "confirm integrity of each script" requirement without freezing the container.
Requirement 11.6.1: The Change Detection Monitor
Requirement 11.6.1 requires a change- and tamper-detection mechanism to alert personnel to unauthorized modification of HTTP headers and the contents of payment pages as received by the consumer browser. This is a new requirement with no v3.2.1 equivalent. Satisfying it requires either: a real-user monitoring implementation that captures and validates the DOM state of payment pages, or a CSP reporting implementation that captures violations indicating unauthorized script execution, or a dedicated payment page integrity monitoring service.
The Customized Approach and When It Makes Sense
The customized approach allows organizations to implement alternative controls that achieve the stated security objective of a requirement. For Requirement 6.4.3, a customized approach might involve a different mechanism for script integrity verification than SRI hashes. The catch: the customized approach requires a QSA to validate the alternative control, and the organization must document the customized implementation controls, the objective(s) the implementation achieves, and the testing approach. For most fintechs, the defined approach is less work.
- Audit your payment page script inventory — every script tag, every dynamically-injected script, every tag manager tag that executes on payment pages
- Implement Content Security Policy with reporting on all payment pages before the v4.0 audit window
- Evaluate 6.4.3 compliance for each third-party script: can it be self-hosted? Does it support versioned URLs with SRI?
- Implement a change detection monitor per 11.6.1 — several commercial tools now support this requirement
- Review your SAQ or ROC scope for any new requirements that apply to your environment
- For Requirement 12.3.2: conduct a targeted risk analysis for requirements that allow flexible implementation frequency
The Development Process Requirements
Requirements 6.2.4 and 6.3.2 are development process requirements: all software development personnel must receive training on secure development practices including OWASP Top 10, and an inventory of bespoke and custom software must be maintained. These are straightforward to implement but require process changes in development organizations that don't currently run structured secure development training. Our compliance infrastructure practice includes PCI DSS v4.0 assessment and remediation as a core service.
EU AI Act: What CTOs Actually Need to Do Before August 2026
DORA Is Live. Here's What 'Operational Resilience' Means for Your Codebase
FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.