Vigilant
Just explore Start now

Payments Glossary · Risk & Compliance

PCI Requirement 6.4.3

Also called 6.4.3, payment page script management

Requires merchants to inventory, justify, authorize and integrity-assure every script that loads on a payment page.

What it is

Requirement 6.4.3 of PCI DSS v4.0 and v4.0.1 applies to payment pages and states that all scripts loaded and executed in the consumer's browser must be managed: a method must confirm each script is authorized, a method must assure the integrity of each script, and an inventory must be maintained with written business justification for each one. It became mandatory March 31, 2025. In plain terms, it asks a merchant to know every piece of JavaScript on the checkout page and be able to prove it has not been altered. That includes analytics tags, chat widgets, ad pixels, A/B testing tools, and anything loaded through a tag manager, because in practice those are the injection routes. The reason it exists is e-skimming, often called Magecart. An attacker compromises a third-party script provider or the merchant's tag manager and injects code that reads the card fields in the browser and sends the data to an attacker-controlled server. The processor never sees anything wrong. The transaction settles normally. The theft happens on the customer's device. Crucially, this can apply even when the card fields themselves are hosted by a processor in an iframe, because the merchant still controls the top-level page, and a hostile script in that page can overlay or redirect the payment experience. 6.4.3 governs what you allow onto the page; its companion, 11.6.1, governs detecting what actually happened.

Why it matters to your business

If you sell online, the practical action is small and free: find out whether your checkout is a full redirect, and if it is not, ask your processor in writing to confirm that its embedded payment solution includes protections against script attacks. That letter can be the difference between a short questionnaire and a much larger obligation. Beyond paperwork, this is the requirement that maps to the attack most likely to actually hurt a small online seller. A skimmer in your checkout does not slow your site down or trigger a decline. You find out when the card brands do a common point of purchase analysis and your acquirer calls. This is education, not legal advice; breach obligations involve state notification law and your merchant agreement, and both deserve counsel.

Where it gets contested

The scoping argument is live and commercially loaded. Client-side security vendors read the requirement broadly and market monitoring subscriptions to any merchant with an online checkout. Assessors and processors often read it narrowly, especially where the payment page is fully redirected to the processor's domain. The Council's own SAQ A revision in v4.0.1 muddied then clarified this. 6.4.3 was removed from SAQ A itself, but an eligibility criterion was added requiring the merchant to confirm the site is not susceptible to script-based attacks. The two accepted paths in FAQ 1588 are do it yourself or get a written attestation from a PCI DSS compliant processor. That attestation letter is the single most under-requested document in small-merchant payments. The unresolved part is enforcement. There is no routine audit of a small merchant's checkout page. The requirement bites after a breach, when the question becomes what controls existed and whether the attestation on file was accurate.

How to check it yourself

Ask whoever maintains your website for a list of every third-party script that loads on the checkout page, with a one-line reason each is there. If nobody can produce that list in an afternoon, you do not currently satisfy 6.4.3, regardless of what your annual attestation says.

Receipts

Claims above that are checkable, with where to check them. Published so you do not have to take anyone's word for it.