Payment page script inventory that stays operational

Define the inventory population before collecting URLs

An inventory is only complete relative to a defined population. Start with one payment journey and list the states that can alter what the browser loads: locale, device layout, consent choice, authenticated or guest checkout, payment-provider response, validation error, and tag-manager branch.

For each state, record the page URL or route, observation method, test time, browser context, and whether the state was reached successfully. This prevents a clean-looking register from hiding an untested checkout branch.

• Treat inline code, modules, workers, tag-manager children, and scripts inserted after user interaction as discoverable objects.
• Record the loader chain, not only the final URL, so the team can identify which system or rule introduced the script.
• Keep failed or unreachable states in the coverage record with an owner and follow-up date rather than silently omitting them.

Why a static spreadsheet fails

Payment pages change outside the main release stream. Marketing tags, consent tooling, payment widgets, CDN resources, and tag-manager rules can alter the scripts seen by a customer without appearing in the application repository.

A useful inventory therefore starts with observed browser-side behavior and is reconciled with the approved register. The register remains a governance record; observation supplies the evidence that it still matches reality.

Minimum data model for every script

A URL alone is not enough to support requirement 6.4.3. Each entry needs enough context for a reviewer to decide whether it is expected, authorized, necessary, and controlled.

• Payment flow and page where the script executes.
• First-party or third-party source, loader, and tag-manager relationship.
• Business purpose, technical owner, approving role, and authorization date.
• Integrity or authenticity method, current review status, and exception reference.
• First seen, last seen, last changed, and linked evidence or incident record.

Select an integrity method that fits the script

Subresource Integrity can be effective for a stable cross-origin resource whose exact bytes and delivery headers are controlled, but it is not a universal answer. Vendor scripts that change in place, inline scripts, dynamically assembled bundles, and loader chains need a documented alternative or complementary method.

The record should name the selected method and why it is suitable: controlled build and release hash, digital signature, restrictive source and nonce policy, provider assurance, monitored content change, or a combination. A label such as “covered by CSP” is not enough unless the organization can explain the policy, deployment mode, exceptions, and evidence.

Make the register part of change management

A new or changed script should enter the same workflow as a production change: request, owner, justification, technical review, approval, release, and post-release verification. Emergency changes need an explicit retrospective review rather than a permanent undocumented exception.

The inventory should also have a periodic control owner. That owner reviews stale entries, scripts without a responsible team, inactive integrations, and differences between the approved state and the live payment flow.

Use control tests instead of trusting the row count

A large register can still be ineffective. Test whether a controlled new script is discovered, whether an unowned record is blocked from becoming approved, whether an expected release updates the right fields, and whether a removed integration is retired without deleting its history.

A useful completion criterion is that an independent reviewer can select any observed script and find the journey, loader, owner, necessity, approval, integrity decision, current status, and source evidence without asking the person who built the spreadsheet.