PCI DSS for small merchants and SaaS: payment pages and SAQ A

PCI DSS version 4.0.1 was published on 11 June 2024 as a limited revision with, in the Council's words, "no additional or deleted requirements". Version 4.0 was retired on 31 December 2024. On 31 March 2025 the future-dated requirements became mandatory, including 6.4.3 and 11.6.1 on payment page scripts. If you take cards on a website, or you build one for customers, this is the version you are assessed against.

What's affected

Requirements 6.4.3 and 11.6.1 are aimed at e-skimming. The PCI Security Standards Council says they focus on "ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering", because scripts in a customer's browser are a significant target for attackers who steal card data.

The picture for small merchants is different from the picture for everyone else:

• SAQ A merchants (card not present, fully outsourced payment, no account data stored, processed or transmitted on their systems) had 6.4.3, 11.6.1 and 12.3.1 removed from SAQ A. They now confirm a new eligibility criterion instead: that their site is not susceptible to attacks from scripts that could affect their e-commerce systems. The Council's FAQ 1588 explains how to confirm this.
• The standard itself still contains 6.4.3 and 11.6.1. The Council states the requirements "were only removed from SAQ A, and they are still in the standard." Merchants on other questionnaires, and service providers, still carry them.
• Version 4.0.1 requirement 8 also exempts non-administrative CDE accounts that authenticate only with phishing-resistant factors from the MFA requirement.

How to check if you're exposed

1. Find out which SAQ your acquirer or payment provider has told you to use. Do not guess from your own reading.
2. Open your checkout page in a browser, look at the Network tab, and list every script it loads.

# Quick inventory of scripts a page references
curl -s https://yourshop.example/checkout | grep -o '<script[^>]*src="[^"]*"' | sort -u

3. For each script, write down why it is there, who authorized it, and who owns it. That list is the core of what 6.4.3 asks for.
4. If your payment form is an iframe or redirect hosted by your payment provider, confirm that in writing from the provider.

What to do now

1. Confirm your SAQ type with your acquirer.
2. Remove scripts you do not need from payment pages. Every tag manager rule is a script.
3. If you are SAQ A, document why your site is not susceptible to script attacks: hosted fields or redirect, a locked-down content security policy, and an inventory of scripts that load on the page.
4. If you are not SAQ A, set up integrity checks and tamper detection on payment page scripts at the frequency the requirement sets (read 11.6.1 for the exact wording). Keep the evidence.
5. If you are a SaaS company whose customers embed your checkout, treat your script as a customer's PCI dependency. Publish your script inventory and change process.
6. Train staff who touch payment pages. Requirement 12.6.3 and 12.6.3.1 cover security awareness and phishing and social engineering awareness.

How to avoid this trap

• Do not assume "we use a payment provider" means SAQ A. Check how the page is built.
• Do not leave marketing tags on checkout pages. They become your unreviewed script list.
• Keep a dated record of authorizations. A script that was "always there" fails the authorization question.

Why it matters

Card skimming through third-party scripts is a quiet attack. The merchant's own code is clean, and the payment page still leaks. Small teams miss it because nothing breaks.

The SAQ A change shows how the standard handles scale: the burden moves to a smaller, more specific question about exposure. That makes the honest answer more important, not less.

Quick check

Sources

• PCI SSC blog: Just published, PCI DSS v4.0.1 (11 June 2024)
• PCI SSC: guidance for e-commerce requirements effective after 31 March 2025