What PCI DSS v4.0.1 Requires for Payment Page Scripts From March 31, 2025, and for SAQ A

E-skimming attacks target scripts running in a consumer’s browser to steal payment card data. The PCI Security Standards Council publishes PCI DSS, a standard for the safe handling of cardholder information.

The version the council’s Document Library features is PCI DSS v4.0.1. Its payment page rules and the deadlines attached to them concern any entity that processes card payments through e-commerce, including third-party service providers.

Which Version of the Standard Applies Now

The council published PCI DSS v4.0 in March 2022. It published v4.0.1 on June 11, 2024 as a limited revision. The revision corrects formatting and typographical errors and clarifies the focus of some requirements. It adds no requirements and removes none. Changes were reviewed in a request-for-comments period from December 2023 through January 2024.

The council counts 64 new requirements in PCI DSS and says 51 of them are future-dated. Version 3.2.1 was retired on March 31, 2024.

The council said PCI DSS v4.0 would retire on December 31, 2024. After that date, v4.0.1 would be the only version the council supports. The council’s document library lists PCI DSS v4.0.1 and a summary of changes from v4.0 to v4.0.1.

The council says the revision does not change the March 31, 2025 effective date for the new requirements. When it announced v4.0.1, the council said the report-on-compliance template, attestation forms and self-assessment questionnaires were targeted for third-quarter publication, with the Prioritized Approach tool to follow.

Retirement Date
The council said PCI DSS v4.0 would retire on December 31, 2024, after which v4.0.1 would be the only supported version. Its future-dated requirements took effect on March 31, 2025.

Payment Page Scripts Under Requirements 6.4.3 and 11.6.1

Requirements 6.4.3 and 11.6.1 cover e-commerce payment pages. They focus on ensuring that payment page scripts are authorized, checked for integrity and monitored for tampering, and they aim to prevent unauthorized changes to web pages.

The purpose, the council states, is to reduce the risk of e-skimming attacks. It describes e-skimming as attacks that target scripts running in a consumer’s browser to steal payment card data. It says these attacks have grown as e-commerce platforms have become more complex and reliant on external scripts.

These requirements were listed as best practice from March 2022 and became mandatory on March 31, 2025. The council says the v4.0.1 revision does not change that date. The council announced an E-commerce Guidance Task Force in November 2024.

The council’s guidance document, Payment Page Security and Preventing E-Skimming, gives implementation advice to merchants and to third-party service providers. It was published as an information supplement on March 10, 2025. The requirements also address managing scripts and security-impacting HTTP headers, whether a change happens on the server or in the consumer’s browser.

The council says the guidance is aimed at any entity that processes card payments through e-commerce, or that operates a webpage affecting e-commerce payment security through embedded iframes. It encourages those organizations to review it as part of their security strategy.

The council says the supplement does not add to, replace or supersede requirements in any PCI SSC standard. It also says the council does not enforce compliance or judge whether specific implementations comply. Entities should check compliance validation and reporting duties with their acquirers or payment brands.

Version 4.0.1 also restores the v3.2.1 wording that limits the 30-day patching expectation to critical vulnerabilities. It adds notes on managing payment page scripts under Requirement 6.

What Changed for Merchants Using SAQ A

The SAQ A changes remove Requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A. Requirement 12.3.1, a targeted risk analysis, supported 11.6.1 only. Those requirements remain in the PCI DSS standard itself.

In their place, SAQ A adds an eligibility criterion. A merchant whose web page embeds a processor’s payment form must confirm that its site is not susceptible to scripts that could affect its e-commerce systems.

FAQ 1588 explains the criterion. A merchant can meet it through techniques like those in Requirements 6.4.3 and 11.6.1, deployed by the merchant or by a third party. It can also obtain confirmation from a PCI DSS compliant third-party service provider or payment processor that supplies the embedded iframe. The council says that provider’s solution, when implemented according to its instructions, includes techniques that protect the payment page from script attacks.

The FAQ, dated February 2025, applies the criterion only to merchants whose web page includes a payment processor’s embedded payment page or form, such as an iframe. It does not apply to merchants that redirect customers to a processor, or that fully outsource payment functions, such as by emailing customers a payment link.

A script provider whose only service is non-payment scripts that cannot affect payment account data is not treated as a third-party service provider for SAQ A purposes.

The FAQ encourages merchants to work with their third-party service provider on secure implementation. It also says merchants should confirm with their acquirer or the payment brands whether they must submit an SAQ and which one applies.

Payment page scripts must be properly authorized, checked for integrity and monitored for tampering.

Requirements 3, 8 and 12 in Version 4.0.1

For Requirement 3, the revision clarifies applicability notes for issuers and issuing-service companies. It also adds a customized approach objective and clarifies applicability for organizations that use keyed cryptographic hashes to render primary account numbers (PAN) unreadable.

For Requirement 8, the multifactor authentication requirement for non-administrative access into the CDE does not apply to accounts authenticated only with phishing-resistant factors.

Requirement 12 clarifies the relationship between customers and third-party service providers. Appendix E drops the customized approach sample templates and points to the templates on the council’s website. Appendix G adds definitions for legal exception, phishing-resistant authentication and visitor.

Where the Changes Reach a Brand’s Checkout

Requirements 6.4.3 and 11.6.1 cover scripts on the payment page. The SAQ A eligibility criterion applies to merchants whose web page embeds a processor’s payment form.

Both the FAQ and the guidance document refer to Requirements 6.4.3 and 11.6.1, so those two requirements connect the payment page rules and the SAQ A criterion.

The council’s document library hosts PCI DSS v4.0.1 and its summary of changes from v4.0. Readers who need the exact requirement wording should use those council documents, along with the council’s FAQ section, which hosts FAQ 1588.