By Tyler Durbin
PCI DSS 4.0.1 added very specific expectations for e-commerce merchants that run payment pages: you need to control which scripts are allowed to run, check those scripts for integrity, and detect unauthorized changes to your payment pages.
The deadline has already passed. The PCI Security Standards Council says the future-dated requirements in PCI DSS 4.0.1 became effective March 31, 2025, including Requirements 6.4.3 and 11.6.1 that target payment page script attacks (often called e-skimming or Magecart-style attacks).
If you take card payments online and your checkout page loads JavaScript, uses third-party tags, or embeds an iframe, this is now a "must address" part of your PCI compliance story. The good news is you can often meet the intent without building a full in-house security program, especially if your payment processor and gateway support the right controls.
They require you to (1) know what scripts are running on your payment page, (2) make sure only authorized scripts can run, (3) check scripts for integrity, and (4) detect changes that could indicate tampering.
PCI SSC explained that Requirements 6.4.3 and 11.6.1 were added to reduce the risk of e-skimming attacks during e-commerce transactions by ensuring scripts are authorized, checked for integrity, and monitored for tampering.
In plain English: if a bad actor injects or alters a script on your checkout page and steals card data, PCI DSS 4.0.1 expects you to have controls that would have prevented it or detected it quickly.
Because modern e-commerce checkout pages are a mix of your code and other peoples code, and attackers target that supply chain.
A typical payment page loads:
Even when you do not store card data, a script running in the browser can still skim payment account data while the customer types. PCI SSC specifically called out e-skimming risk and described the new guidance for preventing it.
Usually yes, but the responsibility can shift depending on how the payment flow is built.
PCI SSC said the guidance is intended for entities that process e-commerce card transactions via embedded iframes or with a web page that can impact the security of e-commerce payments.
Here is the practical way to think about it:
If you are not sure which bucket you are in, start by asking your gateway or processor for a short statement of (a) which SAQ applies, and (b) what they provide to address 6.4.3 and 11.6.1.
It is any page that loads in the customer browser where payment account data is entered or could be exposed.
That usually includes:
If the page can affect the security of payment data, treat it as in scope.
You need a repeatable way to inventory scripts, approve them, and ensure what loads in production matches what you approved.
Common control patterns that map to the intent:
1) Script inventory and change control
- Keep a list of all scripts that can run on payment pages, including third-party tags.
- Require approvals for adding, removing, or updating a script.
2) Content Security Policy (CSP) with strict allowlists
- Use CSP to restrict what domains can serve scripts.
- Avoid broad allowlists like *.example.com when possible.
3) Subresource Integrity (SRI) for static third-party scripts
- If a third-party script is loaded via a URL that does not change often, use SRI hashes so the browser rejects modified content.
4) Tag manager governance
- If you use a tag manager, treat it as production code.
- Limit who can publish changes and require review.
5) Payment page monitoring tools
- Some providers and security tools continuously monitor payment pages for new scripts, modified scripts, or suspicious behavior.
You do not necessarily need all of these. The right mix depends on your checkout architecture.
You need to detect unauthorized changes to payment pages and respond.
PCI SSC described 11.6.1 as part of the set that focuses on monitoring for unauthorized changes to web pages and payment page scripts.
A practical 11.6.1 program usually includes:
PCI SSC removed 6.4.3 and 11.6.1 from SAQ A, but it did not remove the underlying risk or the expectation that your payment page is not exposed to script attacks.
PCI SSC explained that 6.4.3 and 11.6.1 were removed from SAQ A and replaced with new eligibility criteria, including confirming the site is not susceptible to script-based attacks that could affect e-commerce systems.
That means if you rely on SAQ A because you use a fully outsourced payment page, you still need a defensible story about:
After March 31, 2025, the PCI Council says the future-dated requirements in PCI DSS 4.0.1 are no longer "best practices" and must be considered during assessment.
PCI SSC noted that PCI DSS 3.2.1 retired March 31, 2024, and that the future-dated requirements became effective March 31, 2025.
If you have been postponing payment page script controls, you should treat this as a current-year compliance gap, not a next-year project.
Visa frames PCI DSS as required for any entity that stores, processes, or transmits Visa cardholder data, including merchants and service providers.
Visa also says acquirers are responsible for ensuring their merchants validate at the appropriate level and obtain required compliance validation documentation.
The practical takeaway: even if PCI feels abstract, your acquiring bank and processor are the ones who can demand proof, set deadlines, or apply penalties.
Mastercard states that all merchants that store, process, or transmit cardholder data must be PCI compliant, unless otherwise exempt.
Mastercard also publishes merchant level criteria and validation approaches (ROC for Level 1, SAQ for Levels 2 through 4).
One nuance small merchants should understand is that Mastercard says it does not require Level 3 and Level 4 merchants to validate PCI compliance, but it still requires acquirers to maintain a risk management program for those portfolios.
In reality, many acquirers still require annual SAQs and scans because it is the easiest way for them to show oversight.
Start with a fast inventory and close the biggest gaps before you buy tools.
Here is a practical checklist you can complete in a few hours:
If you are on Shopify, BigCommerce, WooCommerce, or a SaaS platform, your best move is often to reduce script sprawl and tighten publishing permissions.
For many small merchants, the cost is mostly internal time unless you need monitoring tooling or security help.
Typical cost buckets include:
If your checkout is custom and you run many third-party scripts, monitoring can be worth it because it reduces both breach risk and investigation time.
If your provider cannot clearly explain scope, SAQ eligibility, and what they do to help with payment page security, it is a warning sign.
Visa notes that acquirers are responsible for ensuring merchants validate appropriately, so your processor has every incentive to push you toward a workable compliance path.
If you keep hearing vague answers, it may be time to consider a processor known for supporting higher-risk or complex businesses with hands-on guidance.
One example is the way high-risk merchants handle compliance and underwriting. Our guide to high-risk merchant accounts explains why underwriting can be strict and why providers may require more documentation: https://merchantalternatives.com/high-risk-merchant-account-startup/
For merchants trying to reduce risk and cost, our breakdown of interchange fees can help you understand the pricing side while you tackle compliance: https://merchantalternatives.com/interchange-fees-explained/
And if you are deciding how the gateway fits into your architecture, our comparison of gateways vs merchant accounts explains where responsibility can sit: https://merchantalternatives.com/payment-gateway-vs-merchant-account/
Save evidence as you go so you are not rebuilding the story at renewal time.
A lightweight evidence set for many merchants includes:
If you are building a custom checkout, also keep a simple diagram of the payment flow showing where card data is entered and which domains are involved.
Someone has to own payment page security, even if you outsource parts of checkout.
In many small businesses, ownership looks like this:
If one person does everything, the key is still to separate duties. The person who can publish tags should not be the only person who reviews them.
| Checkout setup | Where card data is entered | Script risk on your site | Typical PCI impact |
|---|---|---|
| Redirect to hosted payment page | Provider domain | Lower | Often supports SAQ A, depending on implementation |
| Embedded iframe fields | Your domain plus provider iframe | Medium | You still need script governance on the parent page |
| On-page payment fields or direct API | Your domain | Higher | Strongest expectation for script inventory, integrity, and change detection |
| Marketplace or multi-seller checkout | Mixed | Higher | More third parties, more change control needs |
They focus on preventing and detecting payment page tampering, especially e-skimming attacks that inject malicious scripts into checkout pages.
Yes. PCI SSC removed those requirements from SAQ A, but it also added eligibility criteria that require confirming the site is not susceptible to script attacks.
Not always. CSP is a common baseline because it limits where scripts can load from, while SRI is best for static scripts where you can manage hashes.
Your payment processor can reduce scope if you use a hosted payment page or embedded fields, and they may provide monitoring or guidance. You still need to document what you use and how you control scripts on your site.
You may fail a PCI assessment, lose SAQ eligibility, or face pressure from your acquirer. More importantly, you increase the risk of payment card data exposure through your checkout page.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: