PCI DSS 4.0.1 Payment Page Script Rules: What Changed in 2025

On this page 7 sections

1. PCI DSS 6.4.3 and 11.6.1: What Became Mandatory on March 31, 2025
2. Requirement 6.4.3: Inventorying and Authorizing Payment Page Scripts
3. Requirement 11.6.1: Detecting Payment Page Tampering
4. The January 2025 SAQ a Update and Its New Eligibility Criterion
5. Hosted, Embedded, and Redirect Checkouts: Who Is Responsible
6. Analysis: A Low-Cost PCI 4.0.1 Compliance Path for Small E-Commerce Stores
7. Next Steps for Online Merchants

Key takeaways

• Since March 31, 2025, PCI DSS 6.4.3 requires an approved, integrity-checked and documented list of every script on your payment page, and 11.6.1 requires a way to detect when that page is changed or tampered with.
• In January 2025, SAQ A dropped 6.4.3 and 11.6.1 as line items and replaced them with an eligibility statement: your site must not be open to script attacks.
• PCI SSC FAQ 1588 gives stores with embedded payment forms two ways to meet that statement: put the controls in place yourself, or get confirmation from your payment provider. Under FAQ 1588, the script criterion does not apply to stores that fully redirect shoppers to the provider's payment page.
• The cheapest path for most small stores is a checkout with fewer scripts, plus the right confirmation from your provider in writing and a simple script inventory.

If you sell online, two PCI DSS requirements now apply to your checkout page itself. PCI DSS 6.4.3 and 11.6.1 cover the scripts that run on your payment page and how you detect tampering with them. Both became mandatory on March 31, 2025. This guide explains what each one requires and how the January 2025 SAQ A revision changed the form small online merchants fill out. It also sorts out which tasks are yours and which belong to your platform or processor.

This is general information as of October 2026. It is not legal or compliance advice. Your acquiring bank and the card brands enforce PCI rules, so confirm your validation requirements with your acquirer or a Qualified Security Assessor (QSA).

PCI DSS 6.4.3 and 11.6.1: What Became Mandatory on March 31, 2025

PCI DSS v4.0 was released in March 2022. It introduced 6.4.3 and 11.6.1 as "future-dated" requirements so merchants had time to prepare. That period ended on March 31, 2025, and the future-dated requirements are now mandatory in every assessment under PCI DSS v4.0.1. Version 4.0.1 is a limited revision that mostly cleaned up wording.

Both payment page requirements target e-skimming, often called Magecart attacks. In these attacks, malicious JavaScript runs in the shopper's browser and copies card details as the shopper types them. The standard notes that scripts on a payment page can change their behavior without the merchant knowing, and they can also load other external scripts.

A third requirement, 12.3.1 (targeted risk analysis), is relevant because it lets you set your own monitoring frequency for 11.6.1.

Here's what each requirement asks:

Requirement 6.4.3: Inventorying and Authorizing Payment Page Scripts

Requirement 6.4.3 covers every script that loads and runs in the shopper's browser on your payment page. It sets three conditions:

1. Authorization: You have a method to confirm that each script is approved.
2. Integrity: You have a method to confirm that each script hasn't changed since it was approved.
3. Inventory: You keep a written list of every script and a reason each one is needed.

"Every script" goes beyond your payment code. Analytics tags, chat widgets, ad pixels and anything loaded through a tag manager all count if they run on the payment page.

Common ways to meet the requirement include:

• Content Security Policy (CSP) headers
• Subresource Integrity (SRI) attributes on individual scripts
• Specialized tools that monitor scripts in the browser

A basic inventory can be a spreadsheet. Here's an illustrative example for a made-up store:

The last two rows show why the inventory is worth doing. Once you have to write down why a script runs on checkout, the ones without a good reason usually get removed.

Requirement 11.6.1: Detecting Payment Page Tampering

Requirement 6.4.3 puts your payment page into a known-good state. Requirement 11.6.1 tells you when it's no longer in that state.

It requires a change- and tamper-detection mechanism that alerts staff to unauthorized changes to the security-impacting HTTP headers and the script contents of payment pages as received by the shopper's browser. Those changes include indicators of compromise, modifications, additions and deletions.

The mechanism must run either:

• At least once every seven days, or
• At a frequency you set through a targeted risk analysis under Requirement 12.3.1.

The phrase "as received by the consumer browser" is important. The check covers what shoppers actually load, which can include scripts injected by third parties, not just the files on your server. When assessors test this requirement, they look for evidence such as system settings, a list of monitored payment pages, and monitoring logs or reports.

A weekly check works for a site that rarely changes. If you edit your checkout often or rely on many third-party tags, you may need continuous monitoring to catch problems quickly.

The January 2025 SAQ a Update and Its New Eligibility Criterion

Most small online stores validate compliance with Self-Assessment Questionnaire A (SAQ A). It's the shortest form and is meant for card-not-present merchants that fully outsource card data handling to PCI DSS-compliant providers.

On January 30, 2025, the PCI Security Standards Council (PCI SSC) published a revised SAQ A with three changes:

• It removed 6.4.3 and 11.6.1 as questions.
• It removed the related 12.3.1 targeted risk analysis item.
• It added a new eligibility criterion. E-commerce merchants must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

That wording confused many merchants. On February 28, 2025, the Council released FAQ 1588, which gives merchants with embedded payment forms (usually iframes) two ways to meet the criterion:

1. Use techniques such as those in 6.4.3 and 11.6.1 to protect the page from scripts that target card data. You can put these in place yourself or have a third party do it.
2. Get confirmation from your PCI DSS-compliant payment provider that its embedded form protects your payment page from script attacks. This option holds only if you implement the form according to the provider's instructions.

FAQ 1588 also says this criterion does not apply to merchants whose site redirects shoppers to the provider's payment page. Those merchants still have to meet the rest of SAQ A.

Keep two points in mind:

• The requirements still exist. The revision changed how SAQ A merchants report. It didn't change what the standard requires. Merchants who validate with SAQ A-EP or SAQ D still answer 6.4.3 and 11.6.1 in full.
• "Site" can be read more than one way. SecurityMetrics reads FAQ 1588 as limiting "site" to the payment page that hosts the provider's iframe. Other commentators read it more broadly. Ask your acquirer which reading it uses.

Larger merchants assessed with a Report on Compliance (ROC) should also know about FAQ 1331, which the Council revised in August 2026. Under the revised version, a merchant and its QSA can no longer simply agree between themselves to use SAQ A eligibility to mark 6.4.3 and 11.6.1 as not applicable. The acquirer or payment brands now need to agree.

Hosted, Embedded, and Redirect Checkouts: Who Is Responsible

How your checkout collects card data largely determines what you're responsible for. If you're not sure which setup you have, our explainer on payment gateways versus merchant accounts for online stores shows how the pieces fit together.

*Your acquirer confirms which SAQ you use. Treat this table as a starting point, not a ruling.

Shopify Stores

Shopify's standard checkout runs on Shopify's own infrastructure, so you don't directly control much of the payment page. You're still responsible for your annual validation.

• Ask Shopify for its current PCI documentation and a clear statement of which controls it covers.
• Check whether the apps, pixels and custom code you've added can affect checkout.

If you're comparing processing options, MannyPay supports Shopify payment integration.

WooCommerce Stores

WooCommerce runs on WordPress, which you or your host manage, so more of the setup is your responsibility. Your gateway plugin determines whether card fields use a redirect, an iframe or a direct form. Themes and plugins also often load scripts on every page, checkout included.

Confirm how your plugin collects card data before you decide which SAQ applies. Our WooCommerce payment gateway checklist lists questions to ask, and MannyPay offers WooCommerce payment processing.

Other Platforms and Custom Sites

BigCommerce, Magento and custom builds vary widely. If your checkout uses custom code, assume 6.4.3 and 11.6.1 apply in full until your provider and acquirer confirm otherwise.

Analysis: A Low-Cost PCI 4.0.1 Compliance Path for Small E-Commerce Stores

This section is our editorial analysis, not PCI SSC guidance. Most small stores don't need an expensive security platform to meet these rules. They need fewer scripts at checkout and the right documentation.

1. Identify your checkout type. Ask your gateway in writing whether you use a redirect, an embedded iframe or a direct post form.
2. Strip down the checkout page. Remove chat widgets, heatmaps and ad pixels from payment pages unless they have a documented purpose there. Every script you remove is one less to approve, check and monitor.
3. Get the FAQ 1588 confirmation. If you use an embedded form, ask your provider for written confirmation that its solution protects your payment page from script attacks. Also ask for its implementation instructions, and follow them exactly.
4. Keep an inventory anyway. SAQ A no longer asks about 6.4.3 directly, but a one-page script list helps you show that your site isn't vulnerable to script attacks.
5. Add CSP and SRI where you control the page. A developer can usually set these up on a modest budget. Test on a staging site first so you don't break checkout.
6. Schedule change checks. At a minimum, review payment page scripts and headers on a fixed schedule. If your page changes often, consider a monitoring service.
7. Lock down admin access. Attackers often plant skimming code through stolen admin logins or weak plugins. Turn on multi-factor authentication and train staff on social engineering tactics that lead to breaches.

There's a tradeoff to weigh. A redirect checkout carries the lightest script obligations, but it sends shoppers off your site, which can change their checkout experience. An embedded form keeps shoppers on your page, but you have to meet the eligibility criterion. Compare both options against your checkout conversion benchmarks before you switch.

Script security also overlaps with fraud prevention. Bots that test stolen cards on your checkout are a separate problem, but the fix is similar: tighter control over what reaches your payment page. See our guide to stopping card testing attacks on your checkout. For fraud rules that apply to automated buyers, read about preparing your store for AI agent orders through Claude's Stripe Link checkout.

Next Steps for Online Merchants

Before your next annual SAQ is due:

• Confirm your checkout type and SAQ with your acquirer.
• Get your provider's script-protection confirmation or responsibility documents in writing.
• Build your payment page script inventory and date it.
• Set a recurring calendar reminder to review changes.

If you're reviewing your gateway setup at the same time, MannyPay offers online payment processing for e-commerce stores and payment gateway options including Authorize.net and NMI. For help deciding which options to offer shoppers, see our guide to which payment methods your online store should accept. To talk through your setup, request a free quote, and a MannyPay specialist will respond within one business day.

Sources

1. FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants (PCI SSC Blog)
2. Demystifying the January 2025 Updates to PCI DSS SAQ A (cside)
3. PCI SSC Announces Changes to the SAQ A (URM Consulting)
4. Latest Changes to PCI DSS SAQ A (Blackfoot)
5. FAQ 1588 on SAQ A: Clarifications and Common Questions (Jscrambler)
6. PCI DSS 4.0 Update: New SAQ A Eligibility Criteria (Hyperproof)
7. Further Clarification on SAQ A Updates: Requirements 6.4.3 and 11.6.1 (SecurityMetrics)
8. PCI SSC Clarifies Obligations for Ecommerce Merchants That Outsource Payment Card Processing (Davis Wright Tremaine)
9. PCI SAQ A Eligibility in 2026: What Merchants Must Confirm (Payment Review)
10. PCI FAQ 1331 Revised: 6.4.3/11.6.1 N/A Path Narrows (Reflectiz)
11. Recent Update to FAQ Regarding SAQ Eligibility Criteria Could Affect Your PCI DSS Compliance (GuidePoint Security)
12. PCI DSS 6.4.3 and 11.6.1: Payment Page Script Security (Vigilbase)
13. PCI DSS 6.4.3 and 11.6.1: Payment Page Script Security (Cybernion)
14. Introduction of New Requirements (6.4.3 and 11.6.1) for PCI DSS v4.0 (Foregenix)
15. Complying with PCI DSS 11.6.1: Header Tamper Detection (CHEQ)
16. PCI-DSS v4.0.1 Is Fully in Effect and Your Checkout Page May Already Be Non-Compliant (Compass MSP)
17. PCI DSS v4.0.1: What Is Now Mandatory (Securifii)

ME

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.