PCI DSS and the Browser: Payment-Page Security Explained
By CellWall Team | Published September 25, 2026 | Client-Side Security | 6 min read
On this page
- Watch by topic
- Two requirements, two connected questions
- 6.4.3: give every script an accountable purpose
- 11.6.1: look at the received page
- The same URL can produce a different runtime
- Keep the evidence connected to the requirement
- Where SiteWall fits
- Questions about PCI DSS in the browser
- Continue the series
Reading Progress
0%
6 min left
Your checkout can look like a single page while depending on code from several teams and providers. The version your server sends is the starting point. The customer's browser then loads scripts, applies page context, and runs the payment experience.
Episode 6 of The Client Side, Explained introduces two PCI DSS v4.0.1 requirements that bring this browser layer into focus: 6.4.3 for payment-page script management and 11.6.1 for change and tamper detection. Watch the visual overview, then use the explanations below to connect the requirements to everyday work.
Manage which payment-page scripts belong, how their integrity is assured, and why they are necessary. Detect unauthorized changes to the received page and relevant headers, alert responsible people, and preserve the evidence needed to explain the response.
This is an educational introduction to two requirements, not a complete compliance checklist or a determination of your obligations. Confirm scope, assessment method, and validation responsibilities with your assessor and the organization managing your compliance program. PCI SSC's payment-page security guidance provides the authoritative starting point.
Watch by topic
Video chapters
Two requirements, two connected questions
| Requirement | Question to answer | Evidence to connect |
|---|---|---|
6.4.3: payment-page scripts | Which scripts belong here, and how is their integrity assured? | Script inventory, authorization records, written necessity, and integrity methods |
11.6.1: change detection | Did the received page or its security-impacting headers change without authorization? | Evaluations, detected changes, alerts, and investigation records |
6.4.3: give every script an accountable purpose
The film uses a passport for code as a memory aid. A provider name is not enough: the team needs to connect the scripts loaded and executed on the payment page to authorization, integrity assurance, and an inventory with written justification for their necessity.
Questions for each script
Who authorized it, and where is that decision recorded?
What method assures its integrity for this delivery pattern?
Why is it necessary on the payment page, and who owns that purpose?
For example, a fraud-detection integration may have a clear business purpose. That purpose should still be tied to the relevant resources and payment journey. A generic approval for everything a vendor might deliver makes later changes harder to review. The payment-page script checklist goes deeper into implementation and assessment preparation.
11.6.1: look at the received page
The second requirement focuses on change and tamper detection for payment-page content and security-impacting HTTP headers as received by the consumer's browser. It includes alerting responsible personnel about unauthorized modifications. A server-side deployment record alone cannot describe every change introduced later through third-party delivery or dynamic page behavior.
A useful investigation connects the changed content or header with its earlier state, the page and time observed, and the relevant approval record. Not every difference indicates an attack. Routine releases also change scripts. The job is to distinguish expected changes from unauthorized ones and preserve the reason for that decision.
The same URL can produce a different runtime
Imagine your checkout URL and web app deployment remain unchanged. A tag manager publishes a new configuration, a provider loads another dependency, or a script runs only after a particular consent choice. The browser can now receive a different execution path without a new release from your team.
This is why payment-page monitoring needs meaningful coverage of the actual payment journey. Page state, region, session, and third-party loading behavior can affect what an observation captures. A clean observation is evidence of the conditions tested, not proof that every customer received the same runtime.
Keep the evidence connected to the requirement
Record the observation
Identify the script or page change, where and when it was observed, and the available loading and behavior context.
Connect the finding
Link the observation to the relevant requirement, approval record, and reason it needs review.
Record the action
Preserve the owner, investigation, decision, remediation where needed, and validation of the outcome.
Prepare the evidence
Keep those relationships intact in the report so a reviewer can follow the control, finding, and response without assembling disconnected screenshots.
An export is useful when it preserves context. It does not substitute for operating the controls or establish compliance by itself. Teams still need appropriate scope, configuration, ownership, review practices, and assessment evidence over time.
Where SiteWall fits
SiteWall by CellWall helps teams observe browser-side providers and resources, investigate changes, connect findings and actions to individual requirements, and export an audit package. Its PCI DSS payment-page security workflows support the work of understanding what customers received and documenting what the team did about it.
Account for your payment-page runtime
Explore how SiteWall connects observed resources, requirement-level findings, actions, and exportable evidence.
Questions about PCI DSS in the browser
What is the difference between PCI DSS 6.4.3 and 11.6.1?
6.4.3 addresses payment-page script authorization, integrity, and an inventory with written justification. 11.6.1 addresses detection of unauthorized changes to payment-page content and security-impacting HTTP headers as received by the browser, together with alerting.
Does a familiar provider name prove a script is unchanged?
No. A provider can update code or dependencies independently of your web app. Provider identity, script integrity, authorization, and observed behavior answer different questions.
Does every script change mean an incident?
No. Legitimate releases and configuration changes also alter the runtime. Review the change against its purpose, authorization, affected pages, and available evidence before deciding on a response.
Does an audit export make a website PCI DSS compliant?
No. An export helps organize evidence. Compliance depends on the applicable scope, correctly implemented and operated controls, supporting processes, and validation requirements. Confirm these with the organization managing your compliance program.
Continue the series
Next in The Client Side, Explained: how web skimming turns browser access into stolen payment data. Revisit the previous episode for the delivery paths that can bring altered code into a trusted integration.
Earlier episodes, practical guides, and sources
Continue exploring
Read the practical guides that clarify the surrounding risks, controls, and evidence.
Explore the client-side security hub
Client-Side Security
PCI DSS 6.4.3 and 11.6.1: A Practical Payment-Page Script Checklist
Turn PCI DSS payment-page script requirements into an operational checklist for scope, inventory, authorization, integrity, tamper detection, alert response, and assessment evidence.
Client-Side Security
How Browser-Side Attacks Hide in Trusted Code
Watch how compromised providers and dependencies deliver browser-side attacks through trusted code, and why runtime evidence matters beyond vendor approval.
Client-Side Security
How to Build a Third-Party JavaScript Inventory: A Practical Template
Build a living third-party JavaScript inventory that connects every observed script to its provider, owner, purpose, loading chain, browser access, destinations, approval, and review status.