Online checkout security is not only a question of whether a payment provider is reputable. JavaScript running in a customer’s browser can affect what appears on a payment page and where entered data goes. A compromised plug-in, tag manager, or vendor script may therefore create risk even when a merchant never stores card data on its own server.
PCI DSS v4.x addresses this client-side exposure through payment-page script controls. Requirements 6.4.3 and 11.6.1 have been effective since March 2025. The first focuses on managing scripts that load in a consumer’s browser; the second calls for detecting unauthorized changes to payment pages and security-impacting HTTP headers. For a small business, a manageable starting point is to map the checkout experience, assign an owner, and keep evidence that matches what shoppers actually receive.
What the payment-page controls require
Requirement 6.4.3 calls for methods to confirm that payment-page scripts are authorized, assure each script’s integrity, and maintain an inventory with written business or technical justification for why each script is necessary. An inventory is more than a list of vendor names: it should identify the script or source, its purpose, the page where it runs, and the person or process that approved its use.
Requirement 11.6.1 is the detective counterpart. A change- and tamper-detection mechanism must alert personnel to unauthorized changes, additions, or deletions affecting security-impacting HTTP headers and payment-page script contents as received by a consumer’s browser. Its checks are performed at least weekly, or periodically at a frequency set through the standard’s targeted risk analysis process. Alerts should reach someone who can investigate; collecting scan results in an unattended dashboard is not a response process.
The requirements are designed to reduce e-skimming risk, where malicious code on a checkout page can capture payment information. They are not a mandate to install a particular product. PCI SSC’s March 2025 information supplement explains practical implementation approaches, but it does not replace the standard or decide an individual merchant’s assessment scope.
Map the full payment journey
Start by following a real transaction from the storefront to confirmation. Record each page, redirect, embedded payment form, and third-party component along the way. Include pages that can affect the security of a payment page, not just the final screen containing the card fields. A content management system, tag manager, chat widget, analytics tag, or marketing pixel can change over time and may have access to the page context.
Then compare the source you expect to serve with what a browser actually loads. Use the same browser-facing view that a customer would see, and note the page URL, scripts, headers, provider, and loading path. A clean application deployment does not prove that the browser received only approved content: a vendor can update a remote script, a compromised credential can alter a tag, or a configuration change can add a new dependency.
For each item, capture a few essentials:
- Identity and location: Script URL or vendor, the checkout-related pages where it runs, and whether it is first-party or third-party.
- Business need: The checkout task it supports and why the task cannot be met with a smaller or safer alternative.
- Accountability: Business owner, technical contact, approval date, and the change record or review that authorized it.
- Protection: How its authorization and integrity are checked, and how changes are detected and escalated.
Remove scripts with no current owner or defensible purpose. Fewer dependencies make review, testing, and incident investigation easier. Keep the list tied to the live checkout flow rather than treating a one-time spreadsheet as a permanent snapshot.
Make script changes deliberate
Checkout code often changes for legitimate reasons: a payment processor update, a conversion experiment, a new analytics tag, or a site redesign. Make each change visible before it reaches customers. Route requests through an owner who can explain the business purpose, confirm the provider, and assess whether the change affects payment data or the page’s security boundary.
Use a simple approval sequence: document the request and affected pages; check the provider and intended behavior; record why the script is needed; test the change in a safe environment; and compare the deployed page with the approved state. Review important updates from third parties as well as code your team writes. A vendor’s reputation does not remove the need to understand what its code is allowed to do on your page.
Content Security Policy (CSP), Subresource Integrity (SRI), and script-monitoring services can contribute to a control design, but none should be assumed to meet every requirement by itself. CSP can restrict which sources a browser may load; SRI can help verify the expected contents of a static external resource. Dynamic scripts, vendor-managed updates, and the required written inventory still need an operating process. Confirm the design with the organization responsible for your PCI assessment rather than treating a browser setting as a compliance shortcut.
Define who can approve, deploy, and roll back changes. Where practical, separate approval from implementation, restrict administrative access to the site and tag manager, and keep a record of emergency changes for review. Set a process for suspending a script quickly when its behavior or origin cannot be verified.
Monitor what customers receive
Choose a change-detection approach that evaluates the payment page and relevant HTTP headers as a browser receives them. It may be a manual check, automated monitor, or combination, as long as the mechanism covers the applicable pages and meets the requirement’s timing and alert expectations. A weekly review is the baseline unless a properly documented targeted risk analysis establishes a different periodic frequency.
Test the alert path, not only the scanner. Confirm that a change creates a useful notification, names the affected page or element, reaches a responsible person, and has a documented triage path. Agree in advance who can pause checkout, contact the payment provider, preserve evidence, or restore the last known-good version. If a legitimate vendor release triggers a change, retain the validation and approval record rather than dismissing it without review.
Keep records of scheduled checks, findings, exceptions, investigations, and resolution. An alert that is repeatedly closed as a false positive without root-cause review is a signal to improve the baseline or tuning. Protect the monitoring configuration and its credentials so an attacker cannot quietly disable the control that is meant to detect changes.
Keep evidence ready and confirm your validation path
A compact evidence folder makes recurring reviews less disruptive. Maintain the current script inventory and justifications, approvals and change records, integrity-control design, monitoring scope and frequency, recent results, alert tests, and any incident follow-up. Make sure records cover both the design of the control and proof that it operated. If a provider manages part of the checkout, retain its responsibility statement and the evidence or assurance it supplies, then verify that the covered pages and configuration match your implementation.
Do not assume that outsourcing a payment form automatically determines your questionnaire or removes every merchant responsibility. PCI SSC’s FAQ on revised Self-Assessment Questionnaire A describes a specific script-attack eligibility criterion for merchants whose site embeds a third-party payment page or form, such as an iframe. The FAQ describes ways to confirm that criterion and distinguishes embedded forms from redirect and fully outsourced payment flows. The applicable validation route depends on the actual architecture and the acquirer or payment brand’s program; ask your acquirer, processor, or qualified assessor before relying on an SAQ category.
Useful primary references include PCI SSC’s payment-page security supplement at https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming and FAQ 1588 at https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants. Together they can help a merchant frame questions for its provider and assessment partner.
Good payment-page governance is a cycle: know what runs, approve why it runs, detect when it changes, and keep proof of review. The result is a safer checkout and a more focused compliance conversation—not a bigger spreadsheet for its own sake.
