How to monitor checkout changes: what to watch and when

Monitoring checkout changes means knowing, in time to act, when something on the payment page starts behaving in a way the store did not authorize. That includes the files on the server, the scripts the page loads, the security headers and, above all, what appears on the shopper's screen. Each layer needs a different method, and no method sees all four.

Why monitor the payment page and not just the site

The checkout is the only page where an attack turns into money on the spot. Code that copies the card or swaps the Pix QR code (Pix is the instant payment system run by Banco Central do Brasil, Brazil's central bank) only needs to work there, which is why it usually stays switched off on the rest of the site. In September 2026, Brazilian stores hit by code of this kind first saw a business symptom, a rise in Pix drop-offs, before any technical alert.

Monitoring the payment page is also a requirement. Since March 31, 2025, PCI DSS requirement 11.6.1 calls for a mechanism that detects unauthorized changes to the page content and the security headers, checked at least weekly or at the frequency set by the company's own risk analysis.

What to watch: the four layers

1. Files on the server

The platform, theme and plugin files. A change outside a planned release is the most classic sign of a breach.

What this layer misses: code that comes from an external address and only exists in the browser.

2. Scripts loaded by the page

The list of everything the payment page pulls in: your own files, analytics tools, chat, ad pixels, payment provider scripts. This is the inventory that PCI DSS requirement 6.4.3 calls for, with an owner, a reason and an integrity guarantee for each item.

What this layer misses: an already approved script that changes its behavior without changing its name, or an extension in the customer's browser.

3. Security headers

The instructions the server sends the browser along with the page, such as the policy that defines where scripts can load from and where data can be sent. If someone loosens that policy, the door is left open without a single file changing.

What this layer misses: an attack that uses a service that is already allowed. In June 2026, researchers described card-stealing code that used a well-known payment service as a foothold, precisely to get past policies that trusted it.

4. What the customer's screen shows

The Pix QR code, the Pix Copia e Cola text (the text version of the payment code that the customer copies and pastes into their banking app), the linha digitável (the payment number) of the boleto (the Brazilian bank payment slip), the wallet address, the form that takes the credit card and the debit card, and where that form sends the data. This is where the scam happens and where it shows up in full.

What this layer requires: comparing what is on screen with what the store issued, not just recording that something changed.

How often

There is no single frequency. The practical rule is to set one per layer:

• Files on the server: on every release and daily, with an immediate alert for any change outside a release.
• Scripts and headers: continuous, with human review at least weekly, which is the 11.6.1 minimum.
• Customer's screen: on every load of the payment page. A QR code swapped on Tuesday at 10:00 has already received money by 10:01.

Methods and what each one sees

• File monitoring on the server. Good for breaches that touch the store's code. Blind to what is assembled in the browser.
• External scanning by a bot. A bot opens the checkout from time to time and records what the page loads. It helps build the inventory, but it only sees the bot's session, and malicious code can behave differently for visitors that look automated.
• Browser reports on the security policy. The customer's browser reports when something tried to load from where it shouldn't. It shows blocked attempts, not what got through an allowed address.
• Monitoring script on the page itself. It runs in the real customer's browser and sees what the page actually loaded and changed after it opened.
• Payment data check. One step beyond the previous method: besides seeing that the QR code changed, it compares it with the QR code the store issued and blocks it if they don't match.

The first three methods say "something changed". Only the last one says "the customer is about to pay the wrong person".

How to set up alerts someone actually answers

1. Define what is authorized. Without a list of expected scripts and destinations, every alert is noise.
2. Separate urgent from routine. A new script on the payment page and a mismatched QR code are urgent. A version change in an analytics tool is routine, to review during the week.
3. Send urgent alerts to someone who can act. A channel with on-call coverage, not an email inbox.
4. Combine technical and business signals. The pending Pix rate, checkout abandonment and complaints about payments with no order count as much as a file alert.
5. Keep the evidence. Date, page, what changed and who approved it. That is what the PCI DSS auditor asks for and what helps when you explain the incident to the customer.

Quick checklist

• A list of the payment page scripts, with an owner and a reason.
• An alert for files changed outside a release.
• A content security policy with reporting turned on.
• Monitoring in the real customer's browser, not just by a bot.
• A check of the QR code, the Copia e Cola code, the boleto number and the card form against what the store issued.
• A daily dashboard with the pending Pix rate.
• A log of every approved change and every alert handled.

For context on the attacks this monitoring prevents, read Magecart: what it is and how to protect your online store. For the requirements, see third-party scripts on the payment page.

Where Proteside fits in

Proteside covers the second and fourth layers in the shopper's browser: it keeps the inventory of payment page scripts and checks, on every order, whether the QR code, the Copia e Cola code, the boleto number and the card form are the ones the store issued. When they are not, it blocks the swap before confirmation, alerts the store and logs the case as evidence for PCI DSS. See how it works.