To vet third-party scripts on a checkout page, list every script that loads, write down who owns it and why it is needed, remove what has no owner, pin versions you control with Subresource Integrity, and watch for changes. A script you cannot explain should not run where customers pay.
Why checkout scripts are a supply chain issue
A checkout page often loads analytics, chat, tag managers, fraud tools and payment components from other companies. Each one runs with the privileges of your page. If a provider is compromised, or a domain it uses changes hands, the change reaches your customers without any commit in your repository. That is why customer reviewers ask about it.
Step by step
- Inventory. Load the checkout in a browser, open the network panel and record every script domain. Repeat for each step of the flow and for logged in and guest paths.
- Assign an owner. Next to each script write the team or person responsible and the business reason. No owner, no reason, remove it.
- Cut duplicates. Tag managers often load scripts nobody tracks. Review what the tag manager can inject and who can edit it.
- Pin what you can. For scripts that you host or that a provider publishes at a fixed versioned address, add the integrity attribute.
- Restrict sources. Use a Content Security Policy to limit where scripts can load from, so a new unlisted domain is blocked and reported.
- Monitor. Re-run the inventory on a schedule and compare. Treat a new domain as a change that needs approval.
How Subresource Integrity works
MDN explains that Subresource Integrity lets a browser verify that resources it fetches, for example from a CDN, are delivered without unexpected manipulation. You provide a cryptographic hash, and the resource must match it. The integrity attribute holds a hash with a prefix of sha256, sha384 or sha512. If the file changes, the browser refuses to run it.
The limit matters: it fits files that stay the same. Many providers change scripts without notice on purpose, which makes a fixed hash break. For those, rely on inventory, a strict policy and an agreement about change notices instead.
Questions to ask each script provider
- Do you publish versioned, immutable files?
- How do you notify customers of changes?
- What data does the script read on the page?
- Who at your company can publish to the file?
What to show a customer reviewer
A dated script inventory with owners, your Content Security Policy, and a note on how new scripts are approved. Be honest where a script cannot be pinned. Say so and describe the compensating control.
For deeper context on payment page script rules, see our post on PCI DSS small merchants and payment page scripts.
Safeguard focuses on the packages and code you build and ship, such as dependency scanning and SBOMs, so use it for your own bundle while handling live third-party scripts through the steps above. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a tag manager a risk?
It can be, because it can inject other scripts. Limit who can publish changes and review its contents regularly.
Can we rely on the payment provider hosted fields?
They reduce what your page handles, but your page still loads other scripts. Inventory the whole page.
How often should we re-check?
On a schedule you can keep, such as monthly, plus after any change to the checkout.
Sources
Last reviewed: 19 October 2026.
