Skip to main content
Tessera
Requirements Free check Terms
PCI DSS reference

PCI DSS 6.4.3: managing the scripts on your payment page

The authorization, integrity-assurance and inventory obligations for every script loaded and executed in the consumer's browser, as a working checklist.

Standard: PCI DSS v4.0.1 requirement 6.4.3. This is a plain-language reference, not legal advice, and it does not determine your PCI DSS compliance or which questionnaire applies to you. Your acquiring bank sets your reporting obligations.

The short checklist

  1. Confirm each script on the payment page is authorized.
  2. Assure the integrity of each script by a method you can describe and test.
  3. Maintain an inventory of every script with a written business or technical justification.
  4. Keep the inventory current as a change process, not as an annual document.

Who this applies to

6.4.3 applies to merchants validating to SAQ A-EP or SAQ D, and to service providers. It was removed from SAQ A on 31 March 2025 — if you are using an embedded processor form, FAQ 1588 says the separate SAQ A script-security criterion applies and techniques such as 6.4.3 may support it. That criterion does not apply to processor redirects or fully outsourced payment flows. Confirm your scope with the acquirer or payment brand.

The three obligations, separately

  • Authorization is a decision, not a scan: someone accountable says this script belongs here.
  • Integrity assurance is a control: subresource integrity, a CSP with hashes or nonces, or another method you can test.
  • The inventory is a record: every script, and why it is there in business or technical terms.
  • A script you cannot justify is the finding — remove it or write the justification.

Where this usually fails

Rarely at the payment provider's script, which is generally well managed. It fails at the analytics tag added for a campaign, the chat widget added by support, and the tag manager that lets either happen without a code review. First-party scripts are not exempt: your own CDN is exactly where an attacker prefers to land, because nobody is watching it.

Primary source

Read the source rather than a summary of it, including this one: PCI DSS v4.0.1, requirement 6.4.3 — https://www.pcisecuritystandards.org/document_library/?class=pcidss&doc=pci_dss.

What the free check can and cannot tell you

The free check reads the HTML your server returns. It inventories script elements and observed integrity attributes, but it does not inspect HTTP response headers or fetch remote script bytes. Live 11.6.1 monitoring separately fingerprints selected response headers and referenced script contents. The free check does not run the page in a browser, and neither does live monitoring. A script injected at runtime by another script is outside what Tessera can see, and no static check can tell you whether a script is authorized — only you know that.

Reviewed August 2026. The standard and the questionnaires change; confirm against the current text before relying on anything here.

See the scripts on your checkout page and which lack integrity

Preview the synthetic 6.4.3 remediation pack before deciding whether the paid artifact fits your review.

Related

  • SAQ A embedded payment forms: the script-security confirmation
  • PCI DSS 6.4.3 payment-page script inventory template
  • PCI DSS 11.6.1: change and tamper detection on payment pages
  • PCI DSS 5.4.1: anti-phishing controls and your sending domain
Tessera
Independent software from Toledo Technologies LLC.
Terms Privacy Refunds