Session replay on payment pages
Session replay exists to record what visitors do, and a payment page is where you least want that. What the tools mask by default, what that does not cover, and the setup an assessor will accept.
TL;DR
Session replay and PCI DSS
SAFEST OPTION
Do not load session replay on payment pages at all. Most teams lose little by excluding one step of the funnel.
IF YOU KEEP IT
Masking defaults help, but the replay script still runs on the page, so it needs a 6.4.3 justification and change monitoring.
WHAT MASKING MISSES
Masking is done by the replay script in the browser. A changed or compromised replay script can read the field anyway.
Short on time? No session replay tool is PCI safe by default. The configuration is what makes it acceptable.
Are session replay tools safe on payment pages?
No session replay tool is safe on a payment page just by default: the safest setup is to not load it there, and if you must, keep card entry in your payment provider's iframe, confirm the tool masks every input, and treat the replay script like any other payment-page script under PCI DSS 6.4.3. The major vendors mask form inputs or card fields by default, which lowers the risk of recording card data. It does not change the fact that a third-party script with access to the page is running where the card is entered. PCI DSS 6.4.3 requires every script on a payment page to be inventoried, justified and integrity-checked, and 11.6.1 requires changes to be detected. A replay script is no exception.
Why session replay is a special case
Most third-party scripts on a checkout read something incidental: a page view, a click, a conversion. Session replay is built to capture what is on the page and what the visitor does with it, including typing. That is the capability a skimmer needs, already installed and already trusted.
Three things follow. The tool can record card data if its masking misses a field. The vendor, or anyone who compromises the vendor or your tag manager, can change the script that does the masking. And because it is legitimately reading the page, its traffic does not look unusual.
What the main tools mask by default
Vendor documentation, as published on 18 October 2026. Defaults change, so check your own account settings rather than relying on this list.
FullStory excludes card fields marked with the autocomplete "cc-" attributes by default, and says excluded or masked elements never leave the visitor's browser.
Microsoft Clarity says content in input boxes is masked in all modes and cannot be customised.
Contentsquare says form field values are never collected, and replaces card-like numbers in page text with an anonymised token.
Quantum Metric says it blocks capture of passwords, credit cards and CVV2 fields by default.
Notice what the defaults depend on: field types, autocomplete attributes, or number patterns. A custom card field without the standard attributes, a card number echoed back on a confirmation step, or a field rendered in an unusual way can fall outside the rule.
What masking does not cover
The script itself. Masking runs inside the replay script, in the browser. A changed version of that script, from the vendor or from an attacker, decides for itself what to send.
Your tag manager. Anyone who can publish to the container can add replay to the payment page, or change its configuration. See tag manager security.
The page around the iframe. If card entry sits in your payment provider's iframe, the replay script cannot read inside it, because browsers isolate cross-origin frames. It can still read and change the page that hosts the iframe, which is why that page stays in scope. See hosted payment pages and PCI scope.
PCI scope. Masking is a data-handling setting. It is not an inventory entry, a justification or change detection, which are what 6.4.3 & 11.6.1 ask for.
A setup an assessor will accept
If session replay has to run on the payment page, this is the minimum that holds up.
Keep card entry in your payment provider's hosted fields or iframe, so the card never touches your page's DOM
Configure the tool to exclude, not just mask, the payment form and any element showing card details
Load the replay script only where it is needed, and decide explicitly whether that includes the payment step
Add it to the 6.4.3 inventory with a written justification that names the business need on this page
Monitor it for changes and for new destinations, so a modified script raises an alert under 11.6.1
Restrict who can change its configuration, in the vendor console and in your tag manager
See which scripts read your payment form today.
What PCI DSS says
PCI DSS v4.0.1 does not mention session replay by name. It does not need to: requirement 6.4.3 covers every script executed in the consumer's browser on a payment page, and 11.6.1 covers unauthorised changes to that page. In March 2025 the PCI Security Standards Council published an information supplement on payment page security and e-skimming for both requirements, which is worth reading before you decide.
The practical upshot is simple. A replay script on a payment page is a payment-page script. It needs the same justification, integrity assurance and change detection as your analytics tag, and arguably more, because of what it is designed to read.
In the docs
How to do this in Script Monitoring: Payment pages sets which pages are in scope, and Approve or block a vendor records the justification for a replay vendor or blocks it on payment pages.
Sources and methodology
PCI DSS requirement text is from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council. Vendor masking behaviour is quoted from each vendor's own documentation as of 18 October 2026; check your own configuration, because defaults and plans differ. We publish a script monitoring product and that is a bias worth knowing about while you read. Primary sources: PCI SSC information supplement announcement, FullStory privacy settings, Microsoft Clarity masking, Contentsquare personal data handling, Quantum Metric data privacy.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 & 11.6.1.
Frequently asked questions
None is safe purely by default. FullStory, Microsoft Clarity, Contentsquare and Quantum Metric all mask or exclude form inputs or card fields out of the box, which helps. What makes it acceptable is the setup: card entry in your provider's iframe, the payment form excluded, and the replay script inventoried, justified and monitored like every other payment-page script.
Yes, if the replay script is in your 6.4.3 inventory with a justification, its integrity is assured, changes are detected under 11.6.1, and it cannot capture card data. Many teams simply exclude the payment step, which is the easier conversation with an assessor.
No. Masking reduces the chance of recording card data, but compliance with 6.4.3 & 11.6.1 is about the script: that it is authorised, justified, unchanged and monitored. A masked recording from an unmonitored script does not meet either requirement.
The replay script cannot read inside a cross-origin payment iframe. It still runs on the page that hosts the iframe, and that page is in scope for 6.4.3 & 11.6.1, so the script still needs to be inventoried and justified.
Most tools let you exclude URLs or elements in their settings. The more robust option is not to load the script there at all, using a tag manager trigger or a condition in your code that skips payment routes. Then confirm in a real session that it no longer loads.
Not by name. Requirement 6.4.3 applies to all scripts executed on payment pages, and session replay is one of them.
The capability is the same: reading the page and sending data elsewhere. A compromised or maliciously changed replay script could do it, which is why change detection on the script matters more than the masking setting.
If the vendor could affect the security of cardholder data, your PCI programme will usually want it covered by your third-party service provider process under requirement 12.8. Ask your assessor how they treat it in your environment.
Look at what executes in real sessions, not at your tag manager configuration, because tags are often set to fire everywhere. A script inventory built from real sessions shows it, with which tag loaded it.
The same logic applies to any tool that records page content or form interaction. Heatmap and form-analytics scripts are frequent findings on payment pages for the same reason.
Related articles
PCI DSS
How to build a payment-page script inventory
Start from what actually executed, capture the load chain, write justifications per script.
Technical
Tag manager security
A tag container injects arbitrary JavaScript by design. How to secure GTM, Adobe and Tealium.
PCI DSS
Hosted payment pages, iframes and PCI scope
How much scope an iframe removes, and why the page hosting it stays in scope.
Technical
What is script monitoring?
A plain definition: what it records, how it works, and how it relates to PCI DSS.
See what reads your payment form.
Install the tag, mark your payment pages, and see every script that runs there, replay tools included. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.