PCI DSS 4.0.1 for Online Stores: The Payment Page Script Rules Explained

If your online store takes card payments, one of the less-known security standards is likely to touch you: PCI DSS, the Payment Card Industry Data Security Standard. This post explains two newer requirements about scripts on the page where customers pay, in plain terms. It is general information, not a compliance opinion; your payment provider, acquiring bank or a qualified security assessor decides what applies to you.

What PCI DSS is, and where version 4.0.1 fits

PCI DSS is the security rulebook set by the card brands through the PCI Security Standards Council. You meet it through your agreement with your payment provider or bank, not through a government filing. See our PCI DSS glossary entry for the short definition.

The Council's announcement says version 4.0.1 was published on 11 June 2024. It fixes typos and clarifies wording, and adds no new or deleted requirements. Version 4.0 was retired on 31 December 2024, so 4.0.1 is the active version. Requirements that version 4.0 had marked as future-dated became mandatory on 31 March 2025. Two of those are the payment page script rules.

The problem these rules address

A checkout page is rarely just your code. It often loads analytics, chat widgets, ad pixels, fonts, tag managers and the payment form itself. If an attacker alters any one script, they can copy card details as customers type them, a technique often called web skimming or Magecart. The store owner usually learns of it from a bank, weeks later.

Requirement 6.4.3: know and control your scripts

According to published summaries of the standard, this requirement asks the business to do three things for scripts that load and run in the customer's browser on payment pages: confirm each script is authorised, make sure its integrity is checked, and keep an inventory with a written reason why each script is needed. Scripts that another vendor loads in turn are within the idea of the requirement, so a tag manager can quietly widen your list.

Requirement 11.6.1: detect tampering

This is a detection control. It asks for a mechanism that alerts you if the HTTP headers or the content of payment pages are changed without authorisation, as the customer's browser receives them. The check runs at a frequency set by your own risk analysis and at least once every seven days, per the summaries I reviewed. Confirm the exact wording and your frequency with an assessor, because the standard's text itself sits behind the Council's document library.

Does hosted checkout from an Indian gateway take me out of scope?

Not automatically, but it helps a great deal. How a store takes payment decides how much of the standard falls on you:

• Redirect to the gateway's page. The customer pays on a page the provider runs. Your own pages never show card fields, so the payment page script rules are the provider's concern. The Council's FAQ about the simplest questionnaire, SAQ A, says its newest script criterion does not apply to merchants that redirect customers or fully outsource payment functions.
• Embedded form or iframe. The card fields come from the provider but sit inside your page. Then your page can still be changed to attack the visitor. The Council's FAQ says merchants in this group can meet the SAQ A script criterion by using techniques such as 6.4.3 and 11.6.1, or by getting written confirmation from a compliant provider that its embedded solution includes script protections. This applied from 1 April 2025.
• Card fields built on your own server. Your scope is largest and the script rules apply fully, alongside many other requirements.

Many gateways offer both redirect and embedded options. Check which one your integration uses and ask your provider for its written statement on script protection. Our gateway comparison and the payment gateway guide explain the options.

A checklist for store owners

1. Ask your developer exactly how card details are collected: redirect, embedded form or your own fields.
2. Find out which SAQ (self-assessment questionnaire) your acquirer or provider expects you to complete.
3. List every script that loads on checkout pages, including those loaded by a tag manager.
4. Remove anything not needed there. Marketing pixels on the payment step are the first candidates.
5. Write one line per script on why it is needed and who approved it.
6. Load scripts from your own domain or use integrity checks where the vendor supports them.
7. Set up change detection on the payment page, or collect the provider's written confirmation that it covers this.
8. Review the list each time you add a plugin, and keep the notes with your compliance papers.

When to ask for expert help

If you take cards through a redirect and run a small catalogue shop, your obligations are usually modest. If you embed a payment form, run many marketing tools or accept cards on your own server, speak to a qualified security assessor. Penalties and fines for non-compliance are set through your contracts with the acquiring bank, so we cannot give a figure.

What we do on store projects

At VS Tech Builders we build e-commerce stores with the gateway's hosted or embedded checkout rather than custom card fields, and we keep third-party scripts off the payment step by default. If you already have a store and want a script inventory, get in touch. For related news, see the tech news hub.

Sources

Checked on 3 November 2026. Technology changes quickly; always confirm details with the official source before you act on them.

• Just Published: PCI DSS v4.0.1 — PCI Security Standards Council Blog
• FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants — PCI Security Standards Council Blog
• PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1: Client-Side Compliance Guide — c/side

Frequently asked questions

Do PCI DSS 6.4.3 and 11.6.1 apply to a small Indian online store?

It depends on how you collect cards. If you redirect shoppers to your gateway's own page, the script rules sit mainly with the provider. If you embed their payment form on your page, you must protect that page from malicious scripts or get written confirmation from the provider. Ask your gateway or acquirer which questionnaire you must complete.

What is the date these requirements became mandatory?

The PCI Security Standards Council states that the future-dated requirements in version 4.0.1, which include 6.4.3 and 11.6.1, took effect on 31 March 2025. Its separate FAQ on SAQ A eligibility for embedded payment pages applies from 1 April 2025. They are already in force as of November 2026.

Does using Razorpay, Cashfree or PayU make me PCI compliant?

Using a compliant gateway reduces your scope, because the provider handles card data, but it does not remove every duty. You still need to follow the integration method correctly and secure your own pages and admin accounts. Ask your provider which questionnaire applies and what written confirmation it can give about script protection.

What is web skimming on a checkout page?

Web skimming is when an attacker slips a malicious script into a checkout page, often through a third-party plugin or tag, so it copies card details as customers type. It is also called Magecart. The two PCI DSS script requirements exist to make such tampering visible and to limit which scripts can run.