Key points
• The sample must represent actual payment-journey states rather than only repository assets.
• Every record is tested against the same source, loader, purpose, owner, authorization, and integrity criteria.
• A negative test proves that an unknown script cannot become silently approved.
• The output is a reproducible sample with decisions and evidence, not a screenshot of the register.
Short answer: what to test under PCI DSS 6.4.3
The test asks whether an independent reviewer can select any script that actually executes on a payment page and establish where it was observed, what loaded it, why it is needed, who authorized it, and how its integrity or authenticity is controlled without relying on oral context.
This article tests an existing control. The primary inventory guide contains the complete field model, interactive builder, and downloadable CSV template.
Scope of this material
The procedure supports evidence preparation. It does not replace scope determination or the professional judgment of a QSA or other compliance-accepting entity.
Build a representative sample
A minimum sample includes a first-party application bundle, payment-provider SDK, and a script introduced by a tag manager or another dynamic loader. If the journey changes with consent, locale, payment method, error handling, or 3DS, cover those states or retain untested branches as explicit gaps.
Use observed browser behavior as the sample source. Repositories, tag-manager configuration, and supplier lists are reconciliation inputs; they do not prove what the customer browser actually received.
- Record the page state, observation time, and observation method.
- Retain the loader chain through to the final executable resource.
- Treat inline code, modules, workers, and child scripts as observable objects.
- Do not remove unexplained records; assign an exception owner and due date.
Apply consistent acceptance criteria to every record
An approved status is defensible only when the record connects an observed state to a governance decision and a testable technical control.
| Criterion | Pass | Fail | Evidence |
|---|---|---|---|
| Observation | Journey, page state, and time are recorded | A context-free URL only | Snapshot or machine-readable export |
| Loader chain | Loader and child sources are known | Only the top-level tag manager is approved | DOM, network log, or loader chain |
| Necessity | A concrete payment function is stated | Reason says only 'required by business' | Function and impact of removal |
| Owner and authorization | An accountable role and decision reference exist | Owner is unknown or approval is verbal | Change, ticket, or stable ID |
| Integrity control | Method fits the delivery model | Only CSP or SRI is named without configuration | Policy, hash, signature, or monitoring |
| Lifecycle | Dates and retired-record history exist | Record is perpetual or disappears with the script | Status and exception history |
Run negative tests and close differences
A positive reconciliation proves only that the current state matches. In an approved test environment without payment data, introduce a safe unknown source, a child script through an allowed container, and a controlled new first-party bundle version.
Every difference must end in a decision: confirm an expected release, contain an unknown source, issue a time-bounded exception, or escalate. Automatically adding every new state to the allowlist defeats the control.
- A new source cannot become approved automatically.
- A dynamic loader exposes final child resources.
- An expected change links to a release, owner, and new control version.
- A retired script receives a decision without losing history.
Assemble a reproducible review sample
The package should let another specialist reproduce the conclusion for one record: observation scope, script, loader, owner, justification, authorization, integrity method, latest change, and decision on a test deviation.
Exclude PAN, CVC, form values, cookies, authorization tokens, and customer identifiers. Script-governance review needs structural and process context, not payment or secret data.
- Builder and data model: Payment page script inventory
- Evidence map: PCI DSS audit evidence map
Payment-page script inventory template
CSV for a local sample; interactive completion is available in the primary guide.
CSV · UTF-8 · example row is clearly marked
Practical steps
1
Define the payment journey, states, and observation source.
2
Sample first-party, third-party, and dynamically loaded scripts.
3
Test observation, necessity, ownership, authorization, and integrity control.
4
Run safe negative tests in an approved environment.
5
Close every difference with a documented decision.
6
Give an independent reviewer a reproducible sample without secret data.
Questions on this topic
Is a register export enough for QSA review?
No. A reviewer also needs observation boundaries, data provenance, authorization, operation after changes, and examples of decisions on deviations.
Can supplier changes be approved automatically?
Observation can be automated, but treating every new response as approved creates a gap. Define conditions, a decision owner, limitations, and retained evidence first.
Does Cartelta guarantee compliance with 6.4.3?
No. Cartelta can support observation, inventory, history, and evidence. Scope, control design, and the final conclusion remain with the organization and assessor.