Key points
• A static spreadsheet quickly becomes outdated; the inventory should reflect the real page.
• Every payment page script needs an owner, status, and business justification.
• CSP, SRI, and monitoring work best as layers in a managed process.
What 6.4.3 expects
The requirement is not only about listing script URLs. It is about making browser-side code on payment pages governable and reviewable.
A strong implementation combines live discovery, authorization workflow, integrity checks, and evidence retention.
Three layers of control
A practical model separates script inventory, script authorization, and integrity assurance. Missing one layer makes the control harder to defend during audit.
- Inventory: first-party, third-party, and dynamically loaded scripts.
- Authorization: owner, purpose, approval, review date, and status.
- Integrity: SRI, CSP, signatures, monitoring, or other change-control mechanisms.
Why a manual spreadsheet is not enough
Manual inventories drift quickly. Marketing tags change, payment SDKs update, CDNs serve new versions, and tag managers can load scripts dynamically.
The inventory should be based on the real page and the browser activity around it, not only on what the team planned to deploy.
How to connect 6.4.3 with delivery
New scripts should pass through an owner, a business reason, an authorization decision, and a technical check before they reach the production payment page.
Useful controls include CI quality gates, CSP in report-only before enforcement, hash or signature validation where appropriate, and a documented exception process.
A minimum technical script record
Sample a first-party bundle, payment-provider SDK, and tag-manager loaded script. For each, retain the observed source, page state, loader, purpose, owner, approval, integrity method, review date, and linked exception or change.
The record below illustrates a register structure, not a Cartelta API format. Payment-field values, cookies, authorization tokens, and other secrets do not belong in this inventory.
Illustrative machine-readable inventory record
{
"script_id": "script-042",
"payment_state": "checkout.payment",
"observed_url": "https://cdn.example/sdk.js",
"loaded_by": "tag-manager:container-7",
"owner": "payments-platform",
"business_reason": "render hosted payment fields",
"authorization": {
"status": "approved",
"change_id": "CHG-1842"
},
"integrity_method": "documented control for this source",
"first_seen": "2026-07-01T08:15:00Z",
"last_reviewed": "2026-07-15"
}Acceptance tests for the 6.4.3 control
Reconcile the approved register with the live page after a release. A difference must create a decision: confirm an expected change, contain an unknown source, reject the change, or issue a time-bounded exception. Automatically accepting every new state defeats the purpose of the control.
- Expected release: the new hash or version links to an approved change and owner.
- Unknown source: the event contains the page, loader, first-seen time, and assigned owner.
- Stale record: a script no longer observed receives a documented remove-or-retain decision.
- Dynamic loader: the test reveals child sources rather than approving only the top-level container.
- Operating model: Payment page script inventory
- Evidence map: PCI DSS audit evidence map
Practical steps
1
Build a live inventory of payment page scripts.
2
Assign an owner and business justification to every script.
3
Add integrity or authenticity controls to the change process.
4
Review the approved state regularly and retain evidence for audit.
Questions on this topic
Is CSP enough for PCI DSS 6.4.3?
No. CSP is useful, but it does not replace the need for an inventory, authorization status, business justification, and evidence.
Can the script inventory be maintained manually?
A manual inventory can be a starting point, but production checkout pages change too often for a static list to remain reliable. The stronger approach is to compare the real page against the approved state.