Script monitoring for SaaS billing and upgrade pages
Your payment page is usually a modal inside the product, which is why it is often the last page anyone thinks to scope. The requirement does not care that it is a React route rather than a checkout.
Start for free
Talk to an expert
TL;DR
SaaS and software and the client-side requirements
THE OBLIGATION
PCI DSS 6.4.3 and 11.6.1 have been mandatory since 31 March 2025 for any page where a cardholder enters, reviews or confirms card data.
THE SPECIFIC DIFFICULTY HERE
The upgrade flow is a component inside the app, so it inherits every analytics, session replay and support script the rest of the product loads.
WHAT THE TAG PRODUCES
A script inventory with justifications, a weekly header change record, runtime blocking, and an evidence pack for your assessor.
Short on time? Your billing screen is a payment page even when it is a route rather than a URL.
How scope is defined
Does saas and software need PCI DSS script monitoring?
Yes, if you operate any page where a cardholder enters, reviews or confirms card data, which includes pages that embed a payment iframe. Your payment page is usually a modal inside the product, which is why it is often the last page anyone thinks to scope. The requirement does not care that it is a React route rather than a checkout. Requirements 6.4.3 and 11.6.1 apply to those pages regardless of platform, and have done since 31 March 2025.
Where the exposure is
The upgrade flow is a component inside the app, so it inherits every analytics, session replay and support script the rest of the product loads
Product analytics and session replay are installed globally by default, which means they are running on the billing screen whether or not anyone decided that
A single-page application has no separate checkout document, so scope has to be defined by route rather than by URL, and most tools cannot do that
Nobody owns this: engineering sees a Stripe component, security sees a SaaS app, and neither sees a payment page in PCI scope
What the inventory shows you
Every script executing on the billing route, including ones loaded by your own bundle
Session replay or product analytics reading card fields inside the upgrade modal
A dependency shipping changed code into production, caught by payload hash
Route-level scoping, so the billing screen is monitored and the rest of the app is not, which also keeps the page-view count small
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
The two requirements, in this context
Frequently asked questions
Read the FAQ
Yes, the page hosting it is. The provider’s element protects the field itself. It does not protect the page around it, where an overlay, a keystroke listener or a session replay tag would sit, and that page is yours.
Yes. Scope is defined by route and selector rather than by document, so the billing route is monitored and the rest of the application is not. That is also what keeps the metered page-view number close to your billing traffic rather than your whole product.
No, not directly, and it is worth being precise. This covers PCI DSS 6.4.3 and 11.6.1. It produces change-detection and inventory evidence that some SOC 2 change-management controls can reference, but it is not a SOC 2 tool and will not get you a report.
That is the right instinct and the answer is that this is not one. The tag is asynchronous and fail-open: if our service is unreachable, your app renders and your upgrade completes. Start in monitor-only mode so nothing is blocked until you choose it.
Yes, unless you scope it properly, which is the point of hashing payloads rather than watching URLs. Your own bundle changing on every deploy is expected and can be authorised as a pattern. A third party changing is the signal you actually want.
There is an install path for each. See the quickstart for HTML, Next.js, Vite, the CLI and the AI-assisted path.
No, and the volume is the reason it is cheap. Page views are the only metered unit, so a billing route with low traffic costs very little, and the free plan covers 1,000 page views a month permanently.
Usually an enterprise prospect’s security review, or your acquirer at SAQ time. Both arrive with a deadline attached, which is why the evidence pack matters more than the dashboard.
See the scripts on your own payment pages.
Free forever on 1,000 page views a month, no credit card. Unlimited domains on every plan.
Free forever plan. No credit card.