# Payment page scripts and PCI DSS: FAQ (/en/blog/pci-payment-page-scripts-faq) These are the questions e-commerce and compliance teams ask most often about PCI DSS requirements [6.4.3](/en/blog/pci-dss-6-4-3) (manage every payment page script) and [11.6.1](/en/blog/pci-dss-11-6-1) (detect changes to payment page scripts and headers). Each answer is short and points to the primary source. The main one is the PCI SSC information supplement *Payment Page Security and Preventing E-Skimming* (March 2025), called "the supplement" below. None of this replaces your assessor. Where an answer is a judgment call, it says so. ## Scope [#scope] ### Which pages are in scope for 6.4.3 and 11.6.1? [#which-pages-are-in-scope-for-643-and-1161] The payment page itself, and any page that embeds a payment form in an iframe (the "parent page"). The supplement says embedding a provider's form does not remove the parent page from scope. Pages that only redirect the shopper to a provider's hosted page are out of scope for these two requirements, but the scripts that perform the redirect are in. In a single-page application, every view that could affect the payment form is in scope, because scripts stay loaded across views. ### Do iframes or hosted payment fields (Stripe, Adyen) take me out of scope? [#do-iframes-or-hosted-payment-fields-stripe-adyen-take-me-out-of-scope] They reduce scope, they do not remove it. The scripts inside the provider's iframe are the provider's responsibility. The scripts on your page that holds the iframe, including the provider's own loader such as `js.stripe.com`, are yours. If a script of yours creates the iframe, it is a payment page script. Adyen's [script security guide](https://docs.adyen.com/development-resources/pci-dss-compliance-guide/script-security) lists the domains its components load from and publishes SRI hashes per release; Stripe lists its [CSP directives](https://docs.stripe.com/security/guide). Both are a good base for your inventory. ### Should browser extension scripts be included in my PCI DSS scope? [#should-browser-extension-scripts-be-included-in-my-pci-dss-scope] Generally no, but write the reasoning down. The supplement does not mention browser extensions, and we found no PCI SSC FAQ on them. 6.4.3 covers the scripts your payment page loads; an extension's script is injected by the visitor's own software, which you cannot authorize or control. Record that position in your script management procedure and agree it with your assessor. ### How do I scope browser extension scripts out without hiding real ones? [#how-do-i-scope-browser-extension-scripts-out-without-hiding-real-ones] Use an ownership test, not an annoyance test: would the page load this script for a visitor with a clean browser profile? If yes, it is yours and stays in the inventory. Extension scripts are usually recognizable by their URL scheme (`chrome-extension://`, `moz-extension://`, `safari-web-extension://`), which makes them easy to filter. Be more careful with software that looks external but arrives over the network, such as a translation proxy or an accessibility overlay: exclude it only with a narrow, documented rule. In CentralCSP, extension scripts are filtered out before they reach the inventory, and other visitor software can be excluded with an [exclude rule](/en/docs/platform/features/pci-dss/justification-rules) whose reason appears in the evidence pack. ### Are tag managers in scope? [#are-tag-managers-in-scope] Yes, if the container loads on a payment page. The container script and every tag it injects are payment page scripts, each needing an inventory entry, a justification and an integrity method. The supplement names tag management among the third-party script types attackers may manipulate. The simplest control is to keep the container off payment pages, or to give checkout its own short, reviewed container. ### Do 3-D Secure scripts count? [#do-3-d-secure-scripts-count] No, for 6.4.3. The supplement exempts scripts run by the 3DS provider to perform 3DS, "due to the inherent trust relationship" with the merchant. Any script that runs for another purpose is in scope. ## SAQ A [#saq-a] ### Do 6.4.3 and 11.6.1 apply to SAQ A merchants? [#do-643-and-1161-apply-to-saq-a-merchants] Not as listed requirements since the January 2025 SAQ A revision. Instead, SAQ A has an eligibility criterion: "The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." ### Am I still eligible for SAQ A, and how do I confirm the script criterion? [#am-i-still-eligible-for-saq-a-and-how-do-i-confirm-the-script-criterion] Your acquirer decides which SAQ you file. Per [PCI SSC FAQ 1588](https://www.pcisecuritystandards.org/faqs/1588), the script criterion only concerns merchants whose page embeds a provider's payment page or form (for example an iframe), not merchants who redirect or fully outsource. You can meet it in one of two ways: apply techniques such as those in 6.4.3 and 11.6.1 to your page, or get confirmation from your PCI DSS compliant provider that its embedded solution, implemented as instructed, protects your page from script attacks. Keep that confirmation in writing. ## Building and keeping the inventory [#building-and-keeping-the-inventory] ### How do I inventory fourth-party scripts that vendors load? [#how-do-i-inventory-fourth-party-scripts-that-vendors-load] From the browser. The supplement notes that third-party servers can load scripts "from additional parties (fourth-party servers and beyond)". They do not appear in your HTML or your build, only at runtime. Three ways to see them: * **CSP hash reporting**: add `'report-sha256'` to `script-src` and a `report-to` endpoint. Chromium browsers and Safari then report every script they execute on the page, by URL, whoever loaded it. Run it in `Content-Security-Policy-Report-Only` mode first, so nothing breaks. * **CSP violation reports**: a script from an origin outside your policy produces a report from any current browser. * **A browser session**: the Network panel of developer tools, or a headless crawl, shows what one session loaded. Good for a first look, incomplete as an inventory. [Building a script inventory from CSP hash reports](/en/blog/script-inventory) shows the headers and the report format. ### How do I keep a payment page script inventory current without spreadsheets? [#how-do-i-keep-a-payment-page-script-inventory-current-without-spreadsheets] Build it from what browsers report rather than from what someone remembers. A report-based inventory updates whenever a real session loads a new script, and a changed hash marks an approved script for review. The supplement accepts a spreadsheet for simple sites; the trouble is that a spreadsheet is a snapshot, while third-party scripts change without notice. If you keep one, re-check it against browser data at least as often as your 11.6.1 cadence. ### How can I justify every script on my payment page? [#how-can-i-justify-every-script-on-my-payment-page] Write one line per script that answers: what does it do, why must it run on this page, who owns it, and how its integrity is assured. "Stripe.js tokenizes card fields, required for checkout, owner Payments team" is a justification. "Needed" is not. If you cannot write a reason a stranger would accept, the honest outcome is to remove the script. The [6.4.3 guide](/en/blog/pci-dss-6-4-3#a-justification-template) has a copyable template table. ### What do assessors think about automated script justification? [#what-do-assessors-think-about-automated-script-justification] PCI DSS does not require authorization or justification to be manual. The supplement says the standard does not specify "whether the process is manual or automated", and that the evidence depends on which methods you use. Whether a specific automated approach is sufficient is your assessor's call. In practice, an automated approval holds up when a named person defined the rule, the rule is narrow (one vendor, one path), its written reason is specific, and a script whose content changes comes back for human review instead of staying approved. ## Evidence [#evidence] ### What evidence does a QSA expect for 6.4.3 and 11.6.1? [#what-evidence-does-a-qsa-expect-for-643-and-1161] For 6.4.3: policies and procedures for script management, documented roles, people available for interview, the script inventory with justifications, and system configurations showing how each script is authorized and its integrity assured. For 11.6.1: the mechanism's settings, the list of monitored payment pages, monitoring results, proof that it alerts, the frequency (and the targeted risk analysis if less than weekly), plus the incident response plan entry for these alerts. The supplement's Tables 5 to 10 list them in detail. ### What is the fastest way to produce a PCI script inventory report? [#what-is-the-fastest-way-to-produce-a-pci-script-inventory-report] If you already collect CSP reports, export what you have. In CentralCSP, the [evidence export](/en/docs/platform/features/pci-dss/evidence-export) produces a ZIP with a PDF report and two complete CSVs (the inventory and the change ledger), and the [inventory CSV](/en/docs/platform/features/pci-dss/script-inventory) is one click from the script list. If you start from nothing, the fastest honest path is a report-only CSP with `'report-sha256'` on the checkout, a few days of real traffic, then a review session to write the justifications. The [get-started guide](/en/docs/platform/features/pci-dss/get-started) walks through it. ### What tools automate PCI DSS compliance for checkout pages? [#what-tools-automate-pci-dss-compliance-for-checkout-pages] They fall into four families: agent scripts on the page, proxies or CDN features, scheduled synthetic scanners, and CSP-report collectors, plus the manual approach. [PCI DSS 6.4.3 and 11.6.1 tools compared](/en/blog/pci-dss-script-inventory-tools) sets out what each sees and what evidence it produces. ## Where CentralCSP fits [#where-centralcsp-fits] CentralCSP builds the payment page inventory from CSP reports, with nothing added to the checkout, records a written decision per script in an append-only ledger, alerts when an unjustified script appears or a script's content changes, and exports the evidence pack. It is hosted in France. It helps you meet 6.4.3 and 11.6.1; your QSA decides. See the [PCI DSS page](/platform/pci-dss). ## Sources [#sources] * [PCI SSC, Payment Page Security and Preventing E-Skimming (March 2025), announcement](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming) * [PCI SSC, FAQ 1588](https://www.pcisecuritystandards.org/faqs/1588) * [PCI SSC, document library (PCI DSS v4.0.1, SAQ A)](https://www.pcisecuritystandards.org/document_library/) * [Adyen, Script security for ecommerce](https://docs.adyen.com/development-resources/pci-dss-compliance-guide/script-security) * [Stripe, Integration security guide](https://docs.stripe.com/security/guide) * [WebKit, WebKit features in Safari 18.4 (Security)](https://webkit.org/blog/16574/webkit-features-in-safari-18-4/) ## Related [#related] * [PCI DSS 6.4.3: managing payment page scripts](/en/blog/pci-dss-6-4-3) * [PCI DSS 11.6.1: detecting payment page changes](/en/blog/pci-dss-11-6-1) * [Build a script inventory with CSP hash reporting](/en/blog/script-inventory) * [How attackers abuse Google Tag Manager](/en/blog/google-tag-manager-security-risk)