Every question, answered

Partly, and the carve-out is narrower than it sounds. The January 2025 update exempted SAQ A merchants from certain requirements, but it asks them to confirm their site is not susceptible to attacks from scripts that could affect their ecommerce systems. If you embed a payment iframe, the page around the iframe is still yours and is still where a malicious script would sit. PCI SSC FAQ 1588 sets out two ways to make that confirmation: apply 6.4.3 and 11.6.1 techniques to the page, or get written confirmation from your PCI DSS compliant payment provider that its solution protects your page from script attacks.

Yes, and it is a known evasion rather than a theoretical one. A scheduled scan arrives from a datacentre address with no session, no cart and no consent state, which makes it an identifiable visitor. A payload written to behave for that visitor and misbehave for a real one produces a clean scan and a compromised checkout at the same time.

Yes. Malicious scripts are routinely obfuscated, so de-obfuscation and analysis happen off the page rather than in the visitor's browser. That keeps the analysis cost away from your checkout while still producing a readable answer about what the script does.

No. Software produces controls and evidence, and compliance is a judgement made by your assessor or by you on a self-assessment questionnaire, across the whole standard. Any vendor promising compliance itself from a single tool is overselling, and an assessor will not accept the claim either.

Partly, and it is harder than it sounds. Exfiltration is routinely disguised as an image request, split across several calls, or sent to a domain that looks like a CDN. Watching destinations helps most when you have a baseline of normal destinations to compare against, which is what an inventory gives you.

Yes. Monitor-only mode produces the same evidence, including a record of what would have been blocked and on which pages, with nothing stopped. Most teams run this way for a few weeks while the inventory settles.

Yes. Blocking works at four granularities: by domain, by URL, by payload hash, or by a single capability such as reading form fields. The last one is useful when you need a vendor's script to keep working but want to remove its ability to touch the payment form.

Yes, and it is consistently the noisiest thing we see. The trap is that a container looks trustworthy because of who publishes it: you see Google Tag Manager and assume it is fine. An attacker does not need your container, they inject through a different container loaded as a sub-request, so the origin still reads as Google. What matters is the behaviour of what the container loaded, not the name on it.

No, you choose the pages. Scope is defined by URL pattern, and only pages matching those patterns are monitored and counted. For PCI work that is usually the payment pages on their own. For broader third-party risk, teams widen it to whichever pages carry the most vendor tags.

Often yes, and this surprises people. If the payment form is in an iframe served by your provider, the iframe is theirs, but the page hosting it is yours. A script on your page can reach around an iframe in several well-documented ways, and the page around the iframe is in scope. See hosted payment pages and PCI.

Sometimes, and it is a separate decision. PCI only requires it on payment pages. Teams often extend monitoring to login and account pages, because the same class of script can harvest credentials or personal data, and because GDPR and HIPAA exposure does not stop at the checkout.

Yes, a person. The requirement says alert personnel. A log that nobody is subscribed to does not meet it, and the alert record is the part an assessor asks to see. There are three channels: email, a webhook to any destination you like, or an S3 bucket. All three work, provided a human is genuinely on the other end.

Sometimes. PCI only requires it on payment pages. Many teams extend it to login and account pages because the same class of script can harvest credentials or personal data, and because consent and privacy obligations apply site-wide.

Only the pages you choose. Scope is a set of URL patterns you define with selector rules, and nothing outside those patterns is monitored or counted. Most teams start with payment and login pages and widen later. You can run it sitewide if you want visibility into ad injection and third-party scripts across the whole estate, and then the whole estate is what is metered. The choice is yours and changing it is configuration, not reinstallation.

No, seven days is the stated minimum, with the option to justify a different frequency through a targeted risk analysis under requirement 12.3.1. Continuous evaluation is simply the easiest way to satisfy it, because you never have to argue about the interval and the evidence can state the real frequency rather than the floor.

Yes, and this is the most common gap. The requirement covers all scripts loaded and executed in the consumer's browser on a payment page. If your tag manager loads a vendor and that vendor loads two more, all of them executed on your payment page and all of them belong in the inventory. Starting the inventory from observed sessions rather than from memory is the only reliable way to catch them.

No, and it is worth being precise. 6.4.3 is about authorisation, integrity and inventory. It does not mandate blocking. Blocking is how you act on what the inventory tells you, and some assessors view a control that can only observe as weaker than one that can also stop a script, which is worth confirming with your own assessor early.

Partly, and it is worth running one. A CSP restricts which origins may load scripts and where they may send data, so it raises the cost of the attack. It does not help when the malicious code arrives from an origin you already allowed, which is what happens when a vendor you trust is compromised. That is the most common Magecart route, so CSP alone leaves the main path open.

Partly, and it is a genuinely useful control. A Content Security Policy restricts which origins may load scripts and where data may be sent. It governs origin rather than behaviour, so a vendor you allowed who then gets compromised passes the policy cleanly. That is the most common attack route, so CSP alone leaves it open.

No, and this is a deliberate design boundary. The subject of monitoring is the script, not the visitor: which scripts ran, what they were, what they touched, and where they sent data. The point of the product is noticing when a script reads a card field, not reading it ourselves.

Yes, and inline matters more than people expect. An injected inline script has no URL to allowlist and no file to hash externally, so identifying it by what it does is often the only handle you have on it.

Yes, and this is often missed. 6.4.3 covers every script that loads and executes on the payment page, which includes your own bundle and anything a build-time dependency pulled into it. A backdoored npm package ends up in your first-party code and runs with full page access, so treating first-party as automatically trusted leaves a real gap.

No, and that is the point. A compensating control has to exceed the requirement it replaces, which is a higher bar and a longer conversation with your assessor. This meets 6.4.3 and 11.6.1 directly, so there is no compensating-control argument to make.

Only where you point it. Scope is a set of URL patterns you define, and page views are counted only on pages inside that scope, so watching one checkout flow costs what that flow's traffic costs rather than what your whole site's traffic costs. Widening scope later is a configuration change.

Yes, marginally, like any tag, and it is designed not to be felt. The tag is small, loads asynchronously and is fail-open, so if our service is unavailable your page still renders. The heavy analysis of each script happens off the page rather than in your visitor's browser.

Partly, and it genuinely helps. If the card never enters a field you control, a script on your page has less to read. It is not complete protection: a script on the parent page can overlay a fake form on top of the real one, or read keystrokes before the provider's field receives them. The page hosting the iframe stays in scope for exactly this reason.

No, though it reduces the value of what can be stolen after submission. Tokenisation protects the card once your provider holds it. It does nothing about the moment the customer is typing into a form, which is precisely when a skimmer reads it.

Usually through a third party rather than through you. Compromising a vendor whose script you already load is the most common route, because your allowlist and CSP both still pass. Tag manager access and vulnerabilities in the ecommerce platform itself make up most of the rest.

With selector rules. You define the URL patterns that constitute your payment scope, and that named scope becomes what both requirements are measured against. It also keeps the rest of your site out of the page-view count, so scope and cost move together.

They are different controls. 6.4.3 is an authorisation record: what is allowed on the page and why. 11.6.1 is a change-detection record: what actually changed and who was told. One is a list, the other is a record of what changed, and an assessor will ask about them separately.

It is the runtime half of it. Software supply chain security usually means dependencies you build into your application at compile time. Third-party scripts are dependencies you load at runtime, from servers you do not control, that can change contents without changing version or URL.

They are real options and worth evaluating, especially if you already pay for the platform. Akamai, Cloudflare, Imperva and F5 all ship a client-side module. Three differences are worth checking before you settle. Price: those modules are priced as an add-on to an enterprise platform, and Script Monitoring starts free and publishes every tier up to $799 a month. Focus: client-side security is the whole product here, not one module inside a CDN or WAF suite, so 6.4.3 and 11.6.1 evidence is the thing the roadmap is pointed at. Sampling: we monitor every page view rather than a sample of sessions, and a skimmer that fires on one request in 300 is missed by anything that samples. Ask any vendor what percentage of sessions they actually observe. Our comparison pages go through each one with a genuine strength and a genuine limitation.

The full chain rather than the first link. A tag manager loads a vendor, that vendor loads a CDN helper, and that helper loads a pixel from a company you have never heard of. Each load is recorded with the call stack that triggered it, so the inventory shows the depth rather than stopping at the scripts you added yourself.

They are related and CSP reporting is worth having. Violation reports tell you when something was blocked by policy, which is a narrow slice: it says nothing about scripts your policy allows, and a compromised approved vendor generates no violation at all.

Meaningfully different. A tag manager shows the tags configured in it. It does not show what those tags loaded afterwards, and it does not show anything added outside the container, which includes anything an attacker injected. The container is a list of intentions, not a record of what ran.

Typically far too long: weeks to months is common, because nothing visibly breaks. Payments succeed, orders ship, and error rates do not move. Many merchants first learn about it from an acquirer or card brand raising a common point of purchase, by which point the exposure window is already large.

This is usually quick: most teams have a complete picture within a few days. The tag starts reporting scripts immediately, and the work is reviewing the list rather than building it. The slower part is chasing internal owners for justifications, which is a people problem rather than a technical one.

More than the team expects, and the number itself is less useful than the chain. The consistent finding when teams first look is not the count but the depth: scripts two and three links away from anything anyone approved. We would rather you measure your own than quote an industry average at you.

This comes up in almost every assessment conversation. Assessors want evidence covering the period being assessed, not a screenshot taken the week you bought the tool. Evidence packs generate weekly from the moment the tag is installed and are retained for 18 months, so the record builds itself from day one rather than being reconstructed under pressure later.

Sometimes, and it depends on your assessor. The requirement says the page as received by the consumer browser, and a scanner receives the page as a datacentre IP with no session, no consent state and no logged-in user. That is a different page from the one your customers get. Some assessors accept scanning, and some do not accept a control that cannot block, so confirm this early rather than after you have bought something.

Yes in principle, and rarely in practice. Nothing in the standard requires a tool. The difficulty is that a spreadsheet records what you believed on the day you wrote it, while 6.4.3 also asks you to assure integrity, which means detecting change. A static list cannot tell you a vendor shipped new code last Tuesday, so most teams end up needing something that watches.

No, it is a subset with a different threat model. Application security typically covers code you wrote and infrastructure you run. Client-side security covers code executing in a browser you do not own, much of it written by third parties, with the malicious traffic never touching your servers.

Yes, exactly the same attack. E-skimming is the term regulators, card brands and law enforcement tend to use, so it appears in PCI SSC and FBI advisories, while security vendors more often say web skimming. There is no technical distinction between them.

Yes, it analyses behaviour, and the distinction is worth pressing every vendor on. Checking a script URL against a list of known-bad domains is cheap, and it only ever catches what is already known. What matters is what the script does: which fields it reads, where it sends data, and whether its payload changed since you approved it.

Yes, still active. The tooling and the hosting have changed, and the underlying economics have not: checkout pages load third-party code, third parties get compromised, and card data is valuable. The two new PCI DSS requirements exist precisely because the card brands consider this an ongoing and growing problem rather than a solved one.

Yes. The iframe belongs to your provider and reduces your scope meaningfully, but the page hosting it is yours. A script on that page can overlay a fake form, capture keystrokes before the iframe receives them, or change the iframe's source. Monitoring has to run on the parent page to see any of that.

No, and we would rather be direct about it. This automates the two client-side requirements, 6.4.3 and 11.6.1, which were introduced in PCI DSS v4.0 and became mandatory on 31 March 2025. The other ten requirement families are outside what a script-monitoring tool can observe. Most customers run this alongside a GRC platform or their QSA's process.

No, though payment pages carry the regulation. Any page that collects something valuable has the same exposure: login forms, account pages, health intake forms, insurance quotes. PCI DSS only mandates controls on payment pages, which is why that is where most programmes start.

No. Error monitoring watches your own code for exceptions, stack traces and performance. This watches all code, most of it third party, for origin, integrity and behaviour. Different signals, different buyers, and only this one is relevant to PCI DSS.

Yes, you can still deploy, and be straight with your assessor about the date. A control that is demonstrably live, with a documented start date and a remediation plan for the period before it, is a much shorter conversation than an open finding with neither. The inventory populates from live traffic within days, so there is something real to show quickly.

This works, and it needs care in configuration. In an SPA the payment step may not be a distinct document load, so scope is defined by the route and the presence of the payment form rather than by a server-rendered URL. Worth confirming during setup so your scope and your evidence line up.

This needs a definition you can defend: a new script origin, a changed payload hash on an approved script, a security header taking a value it has not taken before, or a new outbound destination. Page content that varies by test, locale or consent state is variance rather than change, and a mechanism that cannot tell the two apart produces noise nobody reads.

Hashing counts, and it is the most practical method. You record the payload you approved and detect when what loads no longer matches it. Subresource Integrity achieves this in markup, but it breaks when a vendor legitimately updates, which is why it is rarely used on third-party tags. Pinning approval to the observed payload hash gives the same assurance and turns a vendor update into a review item.

Published: free for 1,000 page views a month, Pro from $99/month for 100,000 payment-page views, $499/month at 500,000 and $799/month at 1,000,000, with overage at $0.0013 per page view and annual billing at 10 months instead of 12. Enterprise is custom. Page views are the only metered unit, and scripts, domains, alerts and users are unlimited on every plan.

This is the question worth asking before you choose anything. Compliance is assessed as of the time of the breach, not the time of your last questionnaire. A forensic investigation that finds the client-side control was inadequate affects your liability position, the fines passed through your acquirer, and in many cases whether your cyber-insurance responds at all. Being able to show what was monitored, and when, is the difference between an argument and a record.

That is the normal case, and it is the reason periodic scanning struggles. Payloads commonly check the URL, the presence of a card field, the card BIN range, the time of day, and whether the browser looks automated. Reporting from 100% of real sessions means the visitor who triggered it is the one who reports it.

Useful terms: a third party is a vendor whose script you added. A fourth party is a script that your vendor's script loaded. Nth party is the general case of a chain of arbitrary depth. They matter because you have no contract with them, often no visibility, and full exposure.

In short: the property that the page received matches the page intended. Assuring it means detecting change across the scripts that execute, the HTTP headers the browser received, and the page content itself. The three surfaces fail differently and are evidenced separately.

There is a real difference, though the terms are used interchangeably. Web skimming is the technique: reading card data from a page in the browser. Magecart refers to the groups who do it, named after early campaigns against Magento stores. In practice a vendor saying Magecart protection and one saying web skimming protection are describing the same capability.

Three things: an inventory of what executes on sensitive pages, integrity pinned to the payload rather than the address, and an alert to a named human when either changes. That is close to what 6.4.3 and 11.6.1 require, which is not a coincidence.

This is the right question to ask of any client-side security product, and the answer is that our own tag is integrity-checked when it loads. If what arrives in the browser is not the script we published, it does not run. This matters more than it first sounds: a monitor an attacker can silently modify is worse than no monitor at all, because it reports all-clear while the page is compromised. It is worth asking every vendor you evaluate whether their agent verifies itself on load, because not all of them do.

The security-relevant ones are what matter: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options and similar headers that change what the browser permits. The requirement says the HTTP headers of the payment page, so the practical approach is to record every distinct value observed per header and let the record show which ones moved.

This is genuinely unclear in most organisations, and the ambiguity is part of the problem. The scripts are added by marketing, the page is owned by ecommerce or web engineering, and the risk lands on security or compliance. Naming an owner is often the first real step.

Yes, it monitors your tag manager, and it is deliberately not installed through one. Those are two different things and the distinction matters. A container is a mechanism for injecting arbitrary JavaScript by design, which makes it one of the more useful things to watch and an attractive target. It also makes it the wrong place to load a monitor from: if an attacker gets container access, a monitor installed through that container can be removed or altered by the same access that let them in. The tag goes in through your own code or your build, so watching the container does not depend on the container.

Yes, the controls are QSA-validated and the evidence pack is built around the four things assessors ask for: the scope, the inventory with justifications, the header change record, and the alerts raised. Assessors do differ on format, so if yours wants something specific it is worth raising with us early rather than the week before your assessment.

Yes, and it is the most underrated control available. Every script on a payment page is both an attack path and a 6.4.3 line item. Requiring a written justification per script tends to remove several, because a number of them turn out to have no owner and no answer to what breaks if they go.

It is the PCI Security Standards Council's February 2025 answer on how an ecommerce merchant meets the SAQ A script eligibility criterion. It applies to merchants who embed a provider's payment page or iframe, not to full redirects, and it gives two routes: protect your payment page with techniques like those in 6.4.3 and 11.6.1, or get written confirmation from your PCI DSS compliant payment provider that its solution protects your page from script attacks.

No, not for their 3DS function. The PCI Security Standards Council says scripts loaded for 3-D Secure, through the iframe your 3DS server provides, do not need validating under 6.4.3, because of the trust relationship you already have with your 3DS provider. Any script that runs for another purpose on the same page is still in scope.

One or two sentences per script: what it does, why it has to run on the payment page rather than only elsewhere on the site, and who owns it. "Stripe.js renders and tokenises the card fields; payments fail without it; owned by Engineering" is a good justification. "Analytics" is not. If nobody can write one, that is usually a script to remove from the payment page.

Yes, it is allowed. PCI DSS names the control, not a product, and the techniques can be run by you or by a third party. A workable setup is a strict CSP with reporting, SRI on static scripts, an inventory with a written justification per script, and a scheduled headless browser such as Playwright or Puppeteer that loads each payment page at least weekly, records every script hash and security header, compares them with an approved baseline and alerts a named person. The cost is upkeep and evidence: scripts injected by a tag manager, or only for some visitors, are easy to miss from one crawler, and you have to keep the records an assessor will ask for.

No. A request you blocked is never counted as a page view, so enforcing more does not cost more.

Partly, and we would rather be precise than boastful here. The in-page engine is a first-party script and is visible in the page like any client-side product, so a determined attacker can study it. What is harder to defeat quietly is the record it leaves: each behaviour is tied to the content hash of the script that ran, a range of detections run off the page against our own fetched copy, and an anti-tamper package makes the in-page detections materially harder to manipulate. A script that behaves differently when it thinks it is watched still leaves a content-hash artefact and a version diff.

In-browser monitoring runs as a script on the page, which is exactly what lets it see real user sessions rather than a scan of a page nobody visited. It also means another script on the same page could in principle interfere with it, so ask any vendor in this category how they mitigate that. Ours is pinned with Subresource Integrity: you install the tag with the hash we publish, the browser hashes the body it receives and compares the two, and it refuses to execute anything that does not match. That holds even if we were compromised. If a different body were ever served to your customers, the browser would reject it rather than run it. If the hash ever did not match, only our tag would be rejected. Your checkout keeps working.

No, and nobody can. Browser same-origin policy prevents any script on your page from inspecting inside a third-party cross-origin iframe, and that is a security feature rather than a limitation of the product. What is detectable, and what matters, is the parent page: a script overlaying the iframe, changing its source, or capturing keystrokes before it.

Yes. Blocking by domain stops everything from that origin, and because the chain is recorded you can see in advance what else would stop, which avoids discovering it in production.

Yes, and this is the common end state. Enforcement is per rule, so teams usually block the clearly unwanted immediately and leave everything else observed while justifications are collected.

Yes. It is in the weekly evidence pack as a PDF for assessors, and available through the API and hourly S3 CSV batches for anything you want to do with it internally.

Yes. Weekly packs are automatic, and you can generate a quarterly attestation pack covering any period you need for an assessment.

Yes. Rules are per alert type, so header changes can go to an email list while malicious outbound connections fire a webhook that pages your security on-call.

Yes, explicitly, along with the selector rule that matched each one, and a list of pages excluded and why. Scope disputes are easier to settle with the list in front of you.

Yes, through the webhook or the hourly S3 CSV batches. That covers SIEMs and observability tools alike, since both accept either an HTTP push or a bucket. Both channels are on Pro and Enterprise plans.

Yes, they are a large part of it. The evidence an assessor asks for is the change detected, when, on which page, and that personnel were notified. All of that is in the alert record and in the weekly pack.

No, and this is a deliberate boundary. The subject of monitoring is the script: which scripts ran, what they were, what they touched and where they sent data. We do not store user-entered values such as card numbers, passwords or form contents.

Yes, and this is a genuine advantage of recording what the browser received. If your origin sets a header and something in the path removes it, the received value is what gets recorded, so the gap is visible rather than assumed away.

Yes, through the webhook, which is how all of them are reached. We do not ship a separate named integration per platform. The webhook sends JSON, Slack Block Kit or Discord payloads, so anything accepting an HTTP request works. There are three channels in total, email, webhook and S3, and we would rather say that plainly than imply a longer list.

No. There is no DNS change and no CDN change, and your site traffic never passes through us. The tag runs on your page and reports. Separately, we fetch the third-party scripts themselves so the heavy analysis happens on our side rather than in your customer's browser.

No, and it should not. A CSP is a browser-enforced origin allowlist and is worth running regardless. These operate at different levels: the policy decides where scripts may come from, blocking rules decide what specific scripts and behaviours are permitted.

No, the price is the same, because the metering is on page views rather than on enforcement. It is the same product with actions withheld.

Yes for 6.4.3 and 11.6.1 as written, because both are about inventory, integrity, detection and alerting rather than blocking. Some assessors prefer a control that can act, so if yours has a view it is better to know it early.

Yes, and that is most of the value. The record is built from what executed in the browser, so a fourth-party script loaded by a vendor's tag appears exactly like a script you added yourself, which is also how the browser treats it.

Yes. The tag is integrity-checked on load, so if the file delivered to the browser is not the one we published it does not run. A monitor that can be silently modified reports all-clear while the page is compromised, which is the worst possible failure mode for this class of product.

No. Scripts, vendors and domains are unlimited on every plan. Page views are the only metered unit, so an accurate inventory never costs more than an incomplete one.

Yes, for the technical control the requirement describes, provided you have alerts routed to a real person and you keep the evidence. Your assessor makes the final call, which is why the evidence pack is built around what they ask for.

There is a middle option: block a single capability rather than the whole script. You can keep a vendor tag running while removing its ability to read form fields, which is often the right answer on a payment page.

This is the central design problem. Only changes against an established baseline raise alerts, and approved scripts stay quiet until their payload hash moves. The weekly digest contains only what changed, so a stable week produces a short read rather than a long one.

From the call stack at load time, which names the script URL, its content hash, and the line and column that triggered the load. That is what makes the chain a record rather than an inference.

Quickly: blocks apply to sessions from the point the rule is live rather than requiring a deployment on your side, because enforcement happens in the tag rather than in your codebase.

A few weeks is typical, and the honest answer is: until the weekly change list is boring. If new scripts are still appearing every day, the inventory has not settled.

Yes for an annual assessment cycle with room to spare. If your situation needs longer, Enterprise retention is configurable.

No. The requirement covers the HTTP headers and the contents of payment pages. Headers are half of it, and page content and script integrity are the other half.

Yes. The 6.4.3 and 11.6.1 dashboard is included on every plan including free. It is not an upsell.

Not usually, and the first thing to check is how many sessions saw it. A script that appears in a single visitor's session is almost always a browser extension running in that person's browser, not something on your page, and every visitor carries their own extensions. A compromise of your own page template shows up across many sessions at once, because every visitor gets the same HTML. The sighting count is therefore the fastest triage you have, and both cases are worth seeing, because an extension reading a payment form is still a real event on a real customer.

Three surfaces: the set of scripts executing and their payload hashes, the security headers as the browser received them, and structural properties of the payment form itself.

A PDF, because that is what assessors ask for and what survives being emailed around. The same data is available through the API and S3 export if you want it in your own systems.

This is the right question to ask of anything on a checkout. The tag is fail-open by design: if it cannot reach us, your page renders and your checkout completes normally. You lose monitoring for that period, and you do not lose your checkout. Enterprise plans carry a 99.9% uptime SLA.

They are captured, and they are often the interesting ones. A script that appears on 0.1% of sessions still enters the inventory, which is exactly the case sampled approaches miss.

You see it, and this is one of the more common real-world events. A new link in the chain appears as a new script requiring action, attributed to the vendor that loaded it.

This is visible, and deliberately so. Acknowledgement is recorded, and unacknowledged alerts appear in the weekly evidence pack, because 'we were alerted and did nothing' is a different finding from 'we were never alerted'.

This is common with a nonce-based policy, and it is handled by comparing policy structure rather than the literal string, so a rotating nonce is not treated as a change. A new directive or a newly permitted origin is.

You are warned prominently. Without a selector there is no inventory to attach to 6.4.3 and no named page to watch for 11.6.1, and that state is visually identical to a healthy domain that has had no traffic, which is exactly the kind of silent failure worth shouting about.

The pack still generates and says so explicitly. A period with no data looks identical to a broken integration unless the report distinguishes them, so it does.

The security-relevant set by default: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy. All observed headers are recorded, and you can add any header to the alerting set.

Because they are assessed separately. 6.4.3 is an authorisation record and 11.6.1 is a change-detection record. An assessor asks about them as two controls, and a single merged report makes you disentangle them under time pressure.

Yes, it can if you block something load-bearing, which is why monitor-only mode exists. It reports exactly what would have been blocked and on which pages, so you can see the consequence before anything stops.

No. Standard pricing for Client-Side Protection & Compliance, the product's current name, is usage-based and not published. Akamai announced a free tier for qualified customers in 2021, up to 1 million analyzed script executions a month, so check whether it is still offered. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

Yes, since March 2026, when Page Shield was renamed Client-Side Security. Client-Side Security Advanced, formerly the Page Shield add-on and the tier with the change detection 11.6.1 needs, is $0.099 per 1,000 requests, self-serve. Ours is metered on payment-page views instead: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

Yes. Business is $999 a year for up to 100,000 page views a month, for one domain and two payment pages. Ours is published too: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view. Compare the domain and payment-page limits, not just the headline figure.

No, and neither does most of this category, which is part of why comparing them is hard. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

No, and neither does most of this category, which is part of why comparing them is hard. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

No, and neither does most of this category, which is part of why comparing them is hard. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

No, and neither does most of this category, which is part of why comparing them is hard. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

Yes, Report URI publishes pricing publicly, which is unusual here. Check their site for current figures rather than trusting a number quoted on a competitor's page.

Yes. Essentials is $98/month for 100,000 page views and one domain, Standard $197/month, Professional $315/month, Enterprise custom. Ours is published too: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view. The headline figures are close, so compare retention and domain limits.

Yes, and it is worth asking every vendor in this category the same question. Our tag is integrity-checked on load: if what arrives in the browser is not the script we published, it does not run. A client-side monitor that an attacker can silently modify is worse than no monitor, because it keeps reporting all-clear while the page is compromised. Not every agent in this category does this, so put it to DataStealth as well.

Usually days rather than weeks. The tag goes in, you mark your payment pages with selector rules, and the inventory populates from live traffic immediately. The slower part is re-recording business justifications, and if you already wrote them for 6.4.3 they transfer directly.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You are already an Akamai customer, the commercial terms are favourable inside your existing agreement, and consolidating vendors matters more than module depth.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You are already on Cloudflare, Client-Side Security Advanced covers your assessor's expectations, and its per-request price works out lower than ours for your traffic. In that case it is the obvious first thing to try.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You want something lightweight and inexpensive, CSP management matters to you, and scanning coverage is acceptable for your risk profile.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. F5 is already in your delivery path and you want to consolidate client-side security into that relationship.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. Your problem is broader than PCI and includes healthcare privacy or detailed consent and tracker governance. Their coverage there is real and we do not compete with it.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You already run Imperva and want client-side and server-side security in one console with one vendor relationship.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You want JavaScript obfuscation and anti-tamper protection for your own application code. That is their strongest capability and it is not something we do at all.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You genuinely cannot add a script to your payment pages. That constraint is real in some organisations, and in that situation a scanner is far better than nothing.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You are deploying or tuning a Content Security Policy and want the best tool for that job. We would genuinely recommend them for it.

Yes, for teams whose primary driver is PCI DSS 6.4.3 and 11.6.1 evidence, who want published pricing, and who want to evaluate on a free plan rather than through a sales cycle. You want to constrain what third-party scripts are capable of rather than observe what they do, and you have the engineering time to tune a sandbox. It is a legitimately strong model.

They suit different constraints. Reflectiz is agentless: it scans your pages from its own infrastructure, so it is the one to pick if you cannot add a tag to the payment page, at the cost of seeing a scheduled visit rather than real customer sessions. Jscrambler comes from JavaScript code protection and runs in the page, which suits teams who also want to protect their own code. Feroot runs in-browser agents and publishes widely cited PCI guidance. None of the three publishes pricing, so compare them on quotes, on whether they observe real sessions, and on the evidence export your assessor will accept.

Akamai sells it as Client-Side Protection & Compliance, with usage-based pricing it does not publish, so any comparison starts with a quote. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Cloudflare's own PCI tier, Client-Side Security Advanced, is $0.099 per 1,000 requests, so at low traffic on Cloudflare it can be the cheapest option. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan. Which is cheapest depends on your page views and how many domains you need.

DomDog is already one of the cheaper options at $999 a year for 100,000 page views, one domain and two payment pages. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

F5 does not publish pricing for Client-Side Defense, and it generally means adopting F5 Distributed Cloud. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Feroot does not publish pricing. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Imperva does not publish pricing for Client-Side Protection. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Jscrambler does not publish pricing. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Reflectiz does not publish pricing. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Report URI publishes its prices, and its PCI features start on the $164.99/month plan. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Source Defense Essentials is $98/month for 100,000 page views on one domain; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Source Defense publishes its prices: Essentials is $98/month for 100,000 page views and one domain. Among tools that publish prices for PCI DSS 6.4.3 and 11.6.1: Script Monitoring is free for 1,000 payment-page views a month and $99/month (or $990 a year) for 100,000, with unlimited domains; cside is free for 2,000 payment-page views a month and $99/month for 100,000; DomDog is $999 a year for 100,000 page views on one domain and two payment pages; Report URI's PCI features start on its $164.99/month plan; and if your traffic is already on Cloudflare, Client-Side Security Advanced is $0.099 per 1,000 requests. Which is cheapest depends on your page views and how many domains you need.

Yes, this is the right thing to worry about, and the answer is that it should not. Installation is one first-party tag with no DNS or CDN change, and the tag is fail-open, so if our service is unavailable your page still renders. Most teams run monitor-only mode alongside their existing tool for a few weeks before switching the system of record.

This is the common trigger. Send the generated evidence pack: the script inventory with a justification per script, the integrity method, the change-detection record for the page and its HTTP headers, and the alerting record. That answers the question with an artefact rather than a paragraph.

Yes. A deposit page where a player enters card details is a payment page, and so is a stored-card management screen. Both belong in scope.

Yes, if they are on a domain you control, and they are unlimited. Domains are never a billing dimension.

Yes, and they are the most commonly missed. Any page where a cardholder enters, reviews or confirms card data is a payment page, which includes adding or editing a saved card for incidentals.

No. Domains, subdomains, scripts and users are unlimited on every plan. Page views are the only metered unit.

No. Domains are unlimited on every plan. Page views are the only metered unit, so adding merchants costs what their traffic costs and nothing more.

Yes, through teams. Each brand can be scoped separately with its own evidence pack, under one organisation for central oversight.

Yes, through teams under one organisation, each with its own scope, alerting and evidence, while the central team keeps the whole view.

Yes, per team, covering their own scope only. That is usually what their assessor asks for.

Yes, if you can justify it and constrain it. Block the capability rather than the whole tag, so replay keeps working everywhere except reading the payment fields. That is usually the version that survives the conversation with the growth team.

Yes. PCI only requires monitoring on payment pages, and nothing stops you scoping other sensitive pages. Page views on those pages count towards your plan like any other.

Yes, and the organisation and team layer exists for exactly that. Each merchant can be a separate team with its own scope, evidence and alerting, under one organisation you administer.

Yes, through teams under one organisation, each with its own scope, alerting and evidence.

Yes, in two stages. Monitoring gives you the record of what was added and when, which is what turns an unenforceable policy into a conversation with evidence. Blocking gives you enforcement when you are ready for it.

No. The tag is engine-agnostic. Where a property uses an engine you cannot modify, the usual route is the tag manager already present on the property site.

Yes. The requirements follow any page where a cardholder enters, reviews or confirms card data, and a donation form is exactly that. Charitable status changes nothing about the obligation.

No. The subject of monitoring is the script, not the visitor. We record which scripts ran, what they were, what they touched and where they sent data. We do not store user-entered values.

No, not the page around it. The iframe is your provider’s, the page hosting it is yours, and an overlay drawn on top of an iframe collects cards perfectly well.

Yes, if a card is entered, reviewed or confirmed on it. The requirement follows the page, not the industry. A quote page that ends in a payment step is a payment page, and so are renewal and instalment pages, which are the ones most often missed.

Yes. Any script that executes in the booking path appears in the inventory regardless of who introduced it, which is usually the first useful thing teams see.

No, and we would rather say so. This covers script integrity and the two client-side PCI requirements. Scalping is a bot management problem and needs a different tool.

Yes, for the code they run on your pages, which is the part in your scope. It does not tell you anything about what happens on the aggregator’s own site, which is their assessment, not yours.

Yes, and this is the case most worth covering. Your iframe protects the field itself. It does not protect the merchant's page around it, which is where an overlay or keystroke capture would sit, and which remains in the merchant's PCI scope.

Partly, and it is worth being precise about how. PCI DSS 6.4.3 and 11.6.1 are what the product is built to evidence. The same visibility shows which scripts read form fields and where they send data, which is directly useful for assessing tracking-technology exposure. It is not a HIPAA compliance programme and we would not position it as one.

No, not directly. This covers PCI DSS 6.4.3 and 11.6.1 and client-side script security. It will tell you what data scripts collect and where they send it, which is often useful evidence in a licensing conversation, but it is not a licensing compliance tool.

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.

No, not on its own, and we would rather be clear about it. This covers two PCI DSS requirements. The change-detection and inventory records can be referenced by change-management controls in other frameworks, but it is not a SOC 2 or ISO tool.

Yes. Installation is one first-party tag, added through your theme, your tag manager, or the platform's script-injection mechanism. Nothing depends on the platform internals. See Shopify and Magento specifics.

This is the main operational challenge here, and the weekly change queue is the answer: only new and changed scripts surface, so a set that churns is reviewable in minutes rather than audited annually.

There is a middle path. Block a single capability rather than the whole script, so the tag keeps working while losing its ability to read the payment form. That is usually the version that survives the conversation.

There is an install path for each. See the quickstart for HTML, Next.js, Vite, the CLI and the AI-assisted path.

Days rather than weeks. The tag goes in, you mark quote, renewal and instalment pages with selector rules, and the inventory populates from live traffic immediately. Writing the justifications is the slower part and it is a writing exercise, not an engineering one.

Minutes for the tag, then an hour or so to mark the billing routes and check the inventory looks right. There is no DNS change, no CDN change and no traffic routed through us. The quickstart covers HTML, Next.js, Vite, the CLI and an AI-assisted path.

Yes, get in touch. The free plan is permanent at 1,000 page views a month with both requirements included, and we would rather you asked than assumed not.

No, and the cost is the reason. Page views are the only metered unit and the free plan is permanent at 1,000 page views a month with both requirements included. A billing route that sees a few thousand views a month is a rounding error next to the deal that asked for it.

No. Monitoring changes nothing by default, and monitor-only mode records what would have been blocked without stopping anything. When you do act, block a single capability rather than the whole tag, so attribution keeps working while losing the ability to read the donation form.

Yes, and temporary is the risk rather than the excuse. A microsite launched for one appeal, tagged heavily for attribution and never reviewed again, is the least-watched payment page most organisations run.

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, and continuous monitoring fits it better than scheduled scanning does. 11.6.1 asks for change detection at least every seven days, but a scan run on a Tuesday tells you nothing about a Friday onsale. Reporting from real sessions means the traffic you actually had is the traffic you have evidence for.

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.

This needs unpicking per page. If the page is on your domain, it is your scope even when a vendor built it. If the payment page is entirely on the vendor’s domain, it is theirs, and the page you redirect from may still matter.

With selector rules rather than a single URL. You define the patterns that constitute payment scope, including steps that render the card form dynamically, and the dashboard shows exactly which pages matched and why.

Yes, and this is the common case. Authorise the tag, record the justification and who required it, then block the single capability you are not willing to grant, such as reading form fields. The tag keeps working and the contractual obligation is met.

Yes, by CSV import or through the REST API rather than adding pages one at a time. If someone has already compiled the list for a previous assessment, that spreadsheet is the input, and pattern rules cover the subdomains behind it.

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, install it when you add billing rather than after. The inventory builds from live traffic, so starting early means you already have a change history when the first security questionnaire arrives, instead of a screenshot taken the week you were asked.

Yes, in most cases, and this is the most common misreading. The January 2025 carve-out is narrower than it looks and does not remove the requirement for every merchant using a hosted page. See SAQ A and the script requirements.

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.

Understood, and the free plan is permanent: 1,000 page views a month with both requirements included and no credit card. For most institutions the paid tier that follows is a small line item next to the assessment itself.

No. Domains are unlimited on every plan and page views are the only metered unit, so a broker network costs what its traffic costs and nothing more.

This is the common case: domains are unlimited on every plan, so you pay for page views across the estate rather than per property.

Usually whoever owns the website, and it is built for that. Install is one tag, alerts go to email or a webhook into whatever chat tool you use, and the evidence pack is generated rather than assembled.

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.

No. Domains are unlimited on every plan, and teams let you keep each client’s scope, alerting and evidence separate under one organisation.

No. Payment-page URL patterns can be imported in bulk by CSV or through the REST API, which is how platforms with large domain lists set up. Compile the list of client URLs that need PCI configuration once, import it, and new campaigns follow the same pattern rules.

No, if it is scoped properly. Your own bundle changing every deploy is expected and can be authorised as a pattern. The alert you want is a third party changing, which payload hashing catches and a version number does not.

Often yes. If the payment form is an iframe served by your provider, the iframe is theirs but the page hosting it is yours, and a script on that page can overlay it or capture keystrokes before it. The parent page stays in scope for 6.4.3 and 11.6.1.

Often yes. If the payment form is an iframe served by your provider, the iframe is theirs but the page around it is yours, and a script on that page can overlay it or capture keystrokes before the iframe ever sees them. See hosted payment pages and PCI.

Often yes, through your tag manager or the booking engine's own script-injection mechanism. Worth confirming during setup, because it varies by engine.

It depends on where the form lives, and this is worth checking rather than assuming. If the donation form is hosted on your domain, the page is your scope. If the platform hosts it entirely on theirs, it is theirs, though the page you send donors from can still matter.

It depends on where the card is entered, and the distinction matters. If you redirect to a page hosted entirely by Stripe, that page is theirs. If you embed Stripe Elements in your own app, the page around the element is yours, and 6.4.3 applies to it. See hosted payment pages and PCI.

The same visibility applies, though the requirement does not. A tag that can read a card field can read a name, an address or a gift amount, and that is a data protection question your privacy notice has to answer even where PCI DSS does not reach.

This is web only. The tag monitors scripts in a browser, so a native app checkout is outside what it can observe. If your app uses a web view for payment, that web view is in scope.

Commonly in scope in practice, because portals usually include stored-card management and bill payment, both of which are payment pages.

It is the canonical case and worth knowing precisely. In 2018 a customised JavaScript file supplied by Inbenta, a third-party chat supplier, was altered and served on Ticketmaster payment pages, capturing card data. Ticketmaster did not write the code and it was not on Ticketmaster infrastructure, which is the point: 6.4.3 exists because a page you own can execute code you did not write and cannot see change.

This is worth separating, because searches for PCI compliance insurance usually come from one of two places. Either a broker portal that takes a card for a first premium, or a carrier renewal page. Both are in scope for 6.4.3 and 11.6.1. Cyber insurance policies are a different subject entirely and are not what this page covers.

A generated pack covering scope, the script inventory with a justification per script, every security-header change with timestamps, and the alerts raised and acknowledged.

A generated pack: scope with the selector rules that matched each page, the script inventory with a justification per script, every security-header change with timestamps, and the alerts raised and acknowledged.

More than people expect. PCI compliance higher education scope usually covers tuition and fee payment, housing and meal plans, parking permits, alumni and development giving, conference and event registration, and campus store checkouts. Each is a payment page under 6.4.3 whether or not it sits on the main domain.

It varies and that is part of the problem. Digital owns the tags, security owns the finding, and compliance owns the evidence. The evidence pack is built to be handed between all three without anyone having to use the console.

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.

Yes. The tag is small, asynchronous and fail-open, so if our service is unreachable your checkout still completes. We are a monitoring dependency, never an availability dependency.

Yes, marginally, like any tag, and it is designed not to be felt: small, asynchronous and fail-open, so if our service is unavailable your checkout still completes.

Partly, and precision matters more than reassurance here. The in-page engine is a first-party script and is visible like any client-side product, so a determined attacker can study it. Harder to defeat quietly is the record: behaviours tie to the content hash of the script that ran, a range of detections run off the page against our own fetched copy, and an anti-tamper package makes the in-page detections materially harder to manipulate.

Yes, a quarterly attestation pack covering any period you need, in addition to the automatic weekly packs.

Yes, through the webhook or the hourly S3 CSV batches, both on Pro and Enterprise. Those two plus email are the three channels, and there is no separate per-platform integration list.

Yes, and scope needs care. In an SPA the payment step may not be a distinct document load, so scope is defined by route and by the presence of the payment form rather than by a server-rendered URL.

No, and we would rather say so. It covers 6.4.3 and 11.6.1. The other ten requirement families need a full-scope platform or your QSA's process.

No, and it does not overlap with one. A WAF inspects traffic arriving at your application. This observes code executing in the browser, where that traffic never goes. They cover different halves.

This is what the archive is for: payloads are kept, so you can diff the malicious version against the version you approved and see exactly what changed and what it was designed to collect.

Generated packs are retained 18 months, which is longer than the raw script history behind them (7, 30 or 90 days by plan). Assessments look backwards, so the artefact is what needs to survive.

Minutes for the tag itself. Adding it through a tag manager needs no deploy at all. The longer part is deciding your payment-page selectors, which is a scoping conversation rather than an engineering one.

Yes, the controls have been validated by a Qualified Security Assessor. Assessors differ on format, so if yours wants something specific it is worth raising early rather than the week before.

Enough to act: the script URL, its content hash, the call stack with line and column, the behaviour observed, the page, the session count, and the archived payload.

A PDF: scope, the script inventory with a justification per script, every security-header change with timestamps, and the alerts raised and acknowledged. Those are the four things assessors ask for.

There is one, as with any tag, and it is designed to be small: the tag is lightweight, loads asynchronously, and the heavy analysis of each script happens off the page rather than in the visitor's browser.

Yes, it will if your policy does not allow it, which is expected and correct. The quickstart covers the directives to add. If you are running a strict nonce-based policy, that is worth raising during setup.

Yes, blocking rules can be created and removed programmatically, which is useful if you want to wire them to an internal approval workflow.

Yes, both the weekly packs and a generated attestation pack for a period you specify.

Yes, and it is a good idea. Use a separate site ID for staging so its page views and its inventory stay separate from production.

No, not necessarily. Installing through a tag manager needs no deploy at all. The HTML, Next.js and Vite paths do.

With an API key created in the console under Developers then API keys. Send it as a bearer token. Keys are scoped to a team.

The Diagnostics page shows deliveries, matched payment-page views and the ratio between them. A domain receiving deliveries but matching no payment pages is flagged, because that looks identical to a healthy domain with no traffic.

With selector rules in the console: URL patterns that define payment scope. That named scope is what both PCI requirements are measured against and what you are billed for.

Yes, and it is generous for reporting use. If you are pulling the full inventory on a schedule, use the hourly S3 CSV export instead, which is designed for bulk.

Yes, covering the inventory, alerts and evidence, with API keys managed in the console. Hourly S3 CSV export is available on Pro and Enterprise.

JSON from the API, PDF for evidence packs, and CSV for the hourly S3 export.

Nothing happens to your site. The tag is fail-open: your page renders and your checkout completes. You lose monitoring for that window, not your checkout.

In the head of every page you want monitored, as high as is practical. It loads asynchronously so it does not block rendering, and being early means it observes scripts that load early.

Yes, if your policy does not allow it, which is correct behaviour. Add our CDN origin to script-src and our ingest origin to connect-src. If you run a strict nonce-based policy, raise it during setup.

Yes, many are, through internationalised domain names. Registries and browsers have added mitigations, including displaying Punycode for suspicious mixed-script domains, and coverage is not complete.

Yes, they are the main one in practice. Each extension can add JavaScript to checkout and can load further code at runtime. All of it is in scope for 6.4.3, including code you never explicitly chose.

Yes, as the build-time half of the same problem. A backdoored package ends up in your bundle and runs with full page access. Lockfiles and provenance help at build time; payload monitoring catches what reaches production.

Partly, and the carve-out is narrower than it sounds. The January 2025 update exempted SAQ A merchants from certain requirements while asking them to confirm their site is not susceptible to attacks from scripts that could affect their ecommerce systems. See SAQ A and the script requirements.

Often yes, and they are the first thing to check if you already pay for the platform. Verify the feature tier you actually have, and confirm the evidence output matches what your assessor expects.

Yes, though not directly from the PCI Council. Fines are levied by the card brands and passed to you through your acquirer. Amounts are contractual and vary. The larger exposure is usually after a breach, where being found non-compliant affects liability, card reissuance costs and your validation level going forward.

Partly, and it depends entirely on the route. A strict CSP is a strong defence against XSS and against unlisted origins. It offers no protection when the malicious code arrives from an origin you already allowed, which is the third-party compromise case.

No, not directly. Browser same-origin policy prevents it, and that is a genuine protection. A script can still overlay the iframe with a fake form, capture keystrokes before the iframe receives them, or swap the iframe's source, which achieves the same result by a different route.

No. Violation reports tell you what was blocked by policy. 11.6.1 asks for detection of changes to payment page content and HTTP headers with alerting to personnel, which is a different record.

Yes, in identifiers and string literals, which makes obfuscated code harder to read and can hide a destination inside otherwise ordinary-looking code.

You can for a public sample, and a good online JavaScript deobfuscator handles the common obfuscators well. Do not do it with a script pulled off your own production checkout during a suspected incident. That uploads evidence to a third party you have no agreement with, and it can put the sample somewhere the attacker can watch. Run the tooling locally instead.

Yes, if they run on the payment page. JavaScript on a page has full access to that page's DOM, including every input. The browser enforces no privilege boundary between your code and a third party's.

Yes. Browser autofill populates fields programmatically, and a listening script sees those values the same way it sees typed ones.

Yes, by a different route. A script cannot read inside the provider's cross-origin iframe, and it can overlay a fake form on top of it, capture keystrokes before the iframe receives them, or replace the iframe's source. The page around the iframe is where that happens.

Yes, with reasonable reliability. Obfuscators leave recognisable structural patterns, and metrics like string entropy, the ratio of dynamic evaluation, and control-flow shape distinguish obfuscated code from merely minified code.

No. A GRC platform organises evidence across the standard without producing the technical controls. A client-side tool produces one control and has nothing to say about the other ten families.

Yes, and they often do. Your acquirer sets your validation requirements and can be stricter than the baseline. If they ask for evidence of script controls despite an SAQ A classification, that is their call to make.

Yes, this is a genuinely useful side effect. The inventory tells you which origins actually load on which pages, which is precisely the input a correct allowlist needs and the thing most teams lack.

Yes, frequently, and it is often the argument that gets it removed when the security argument does not. Forgotten tags still cost bytes, connections and main-thread time on every page load.

Yes, if the container fires on the payment page. Publish access allows arbitrary JavaScript on that page, and JavaScript on a page can read any input on it. That is why publish rights on a container that touches checkout should be treated like production deploy rights.

Yes, through the theme, through checkout extensions where your plan supports them, or through your tag manager. The specifics depend on your plan and checkout configuration, so it is worth confirming during setup.

Yes, through the theme layout, a module, or your tag manager. A self-hosted platform gives you full control over the page, which makes this straightforward compared to a hosted platform.

Partly. Nothing in the standard mandates a tool, and an inventory can live in a spreadsheet. The difficulty is the other half: 6.4.3 also asks you to assure integrity and 11.6.1 asks you to detect change, and a static document cannot tell you a vendor shipped new code last Tuesday.

Partly. A CSP can prevent an unlisted origin loading a script and can restrict where data is sent, which helps. It cannot tell you that an allowed script is reading your card field.

No. 6.4.3 covers scripts loaded and executed on the payment page, not only those that interact with the form. A script's current behaviour is not a guarantee of its future behaviour, which is rather the point of monitoring it.

Yes, usually, and particularly on multi-year commitments or at quarter end. That is true across enterprise security software and is worth knowing before the first call.

Yes, and plenty of teams do. They sit in different places: the WAF in front of your origin, a monitoring tag inside the browser session. There is no conflict, no DNS change and no traffic routed anywhere new.

Yes, and it is common during a migration. Running two client-side tools permanently adds page weight, so be deliberate about which is the system of record for your PCI evidence.

Partly, and it is harder than it sounds. Techniques exist, including iframes with restricted permissions and various proxying approaches, and vendor scripts frequently break under them. Some products are built entirely around doing this well.

Yes, if your merchant level and acquirer permit it. Self-assessment removes the QSA fee and replaces it with staff time, which is not free. It also places the judgement on you, so for a complex environment an assessor is often worth the cost.

Partly, and it is a common reason evidence gets returned. One document is fine; one undifferentiated report is not. Keep the authorisation record and the change-detection record distinct inside it, because the assessor tests them as two separate controls.

Partly, and we would be careful. Payment SDKs update, sometimes urgently for security reasons, and a hash mismatch means your payment form stops working. Most providers advise against pinning their SDK.

Yes, by overlaying a fake form on the iframe, capturing keystrokes at the document level before the iframe receives them, or replacing the iframe's source. The parent page is the attack surface.

No. Every tool on this list addresses the client-side requirements, 6.4.3 and 11.6.1. The other ten requirement families need a full-scope platform or your QSA's process. See best PCI compliance software.

Yes, almost always, because readable card-stealing code is removed the first time anyone looks at the page source. It is a low-cost step with an obvious payoff for them.

Partly. Browsers apply heuristics and display Punycode for domains mixing scripts in suspicious ways. Coverage varies between browsers and versions, so it is a mitigation rather than a solution.

Yes, typically by attaching the evidence pack as documentation against the relevant requirement. Nothing deeper is usually needed, because the artefact is a PDF for a period.

Yes. 6.4.3 covers all scripts loaded and executed in the consumer's browser on a payment page, regardless of the mechanism that introduced them. Everything your container loads belongs in the inventory.

Yes, it depends on your merchant level and your acquirer. Level 1 merchants generally need a Report on Compliance from a Qualified Security Assessor. Lower levels can typically self-assess with a Self-Assessment Questionnaire, though an acquirer can require more. Ask your acquirer rather than inferring from transaction volume alone.

No, and trying to is the most common way this stalls. The decision needs five answers: does it read the form, where does it send, does it load more code, does it change the form, and has it changed. A complete line-by-line reverse is a research exercise, not a prerequisite for removing a script you cannot justify.

Yes, this is the main way merchants acquire obligations. Apps inject JavaScript into your storefront, and any of that executing on a page where a cardholder enters card data is in scope for 6.4.3.

Yes, generally in enterprise tiers. Requiring a second person to approve a publish is one of the most effective controls available, and for a container on a payment page it is usually worth the upgrade.

Yes, substantially. Requirements 6.4.3 and 11.6.1 were introduced in PCI DSS v4.0 and made mandatory in March 2025 specifically because the card brands view browser-based skimming as an ongoing and growing problem that existing controls did not address.

Yes, frequently, and it is one of the easier findings to act on. Orphaned script tags from removed apps keep loading and keep costing page weight, with nobody owning them.

Yes, you can often self-assess, and that is increasingly not the deciding factor. Your merchant level and your acquirer set the formal requirement, and a growing number of enterprise customers now ask their suppliers for a QSA-signed Attestation of Compliance regardless of what the standard would permit. If you sell to large organisations, check your customer contracts as well as your acquirer's requirements before assuming a self-assessment will be accepted.

No, it is entirely optional. The defined approach, meeting the requirement as written, remains available for every requirement and is what most organisations use. The customised approach exists for mature programmes with alternative controls they can evidence.

Partly, and it is harder on a hosted platform where you control less of the header configuration. Where you can set one it is worth doing. Monitoring is usually the more practical control here.

Often yes, and they are not substitutes. A GRC platform tracks evidence across all twelve requirement families. A client-side tool produces the actual technical control for two of them. See PCI compliance software for the distinction.

Yes, if 6.4.3 and 11.6.1 apply to you. A GRC platform gives you a field to attach evidence to; something still has to produce that evidence.

Yes, for cross-origin resources. Without it the browser cannot read the response to verify it, and the resource is blocked.

Yes, if PCI DSS 6.4.3 applies to you. A CSP produces no inventory, no per-script justification and no integrity assurance, which are the three things the requirement asks for.

Yes, if PCI DSS 6.4.3 applies to you, for two reasons. A CSP produces no inventory, no per-script justification and no integrity assurance, which are the three things 6.4.3 asks for. And a strict CSP does not detect a compromised but allowed vendor.

No. Neither requirement mandates blocking. 6.4.3 is authorisation, integrity and inventory; 11.6.1 is detection and alerting. Some assessors view a control that can only observe as weaker than one that can act, so it is worth asking yours directly rather than assuming either way.

No, not for PCI. Many teams do it anyway for login and account pages, because the same class of script can harvest credentials, and because consent and privacy obligations are site-wide.

No, and you cannot. The code inside your provider's cross-origin iframe is their responsibility and their PCI scope, and no script on your page can inspect it. What you monitor is your own page.

Yes, where external vulnerability scanning applies to your validation route, and it must be performed by an Approved Scanning Vendor. Whether it applies depends on your SAQ type, so check which questionnaire you are completing.

No. PCI DSS does not require a Content Security Policy, and a CSP does not satisfy 6.4.3 or 11.6.1 on its own. CSP was designed for a different problem: constraining inline script and controlling which origins may load resources. In practice a policy lands in one of two failure modes. Too strict, and it blocks legitimate vendor scripts and breaks the page. Too permissive, and it allows the thing you were worried about, which is why so many production policies carry 'unsafe-inline' and provide far less protection than they appear to. Either way it produces none of the three artefacts 6.4.3 asks for: no inventory, no per-script justification, and no integrity assurance.

Yes. The parent page hosting the iframe is still a payment page, and it is where an overlay, a keystroke capture or a swapped iframe source would sit. Monitoring runs on the parent page.

Yes, seven days is the stated default, and it is a floor rather than a target. You may define a different frequency through a targeted risk analysis. An attack that runs for six days sits comfortably inside a weekly window, which is why continuous evaluation is the more common answer.

Partly, and it is worth running one. A CSP restricts which origins may load scripts and where data may be sent, which raises the cost of the attack. It does not help when malicious code arrives from an origin you already allowed, which is the most common route.

No, not on its own. A CSP is an origin allowlist: it decides where a script may load from, never what an allowed script does. A breached vendor you already allow passes the policy cleanly. Both controls are worth having. See CSP vs script monitoring.

Partly. It raises the cost, and it does not address the most common route. If the malicious code arrives from an origin you already allowed, which is what happens when a vendor is compromised, every request is permitted and no violation is reported.

Yes, substantially, and it is one of the best defences available. A strict policy using nonces or hashes for inline script blocks injected code from executing even when the underlying application flaw is present. A policy containing 'unsafe-inline' provides much less of this benefit.

Partly, and less than you would hope. A CSP can restrict which origins the container may load scripts from. In practice policies are often written permissively to accommodate the container, which is exactly the loophole an attacker with container access would use.

No, not on its own. 6.4.3 asks for an inventory of every payment-page script with a written business justification and a method to assure the integrity of each. A CSP is an allowlist and produces none of those three artefacts. It is a useful complementary control.

No, negligibly. It is a header the browser evaluates while parsing. The cost is in the engineering effort to get the policy right, not in runtime performance.

Partly. Modern frameworks escape output by default, which removes most classic XSS. They do nothing about a third-party script you deliberately loaded, because that script runs as intended.

Partly. A full redirect to a provider-hosted page means the card is entered on a page you do not control, which genuinely removes most of this risk class. Your own pages can still be modified to redirect customers somewhere else entirely, which is a different attack with the same outcome.

Partly, and it is the strongest version of this model. If the customer types their card on your provider's domain, your page is not the payment page at that moment. Your pages can still be modified to redirect customers somewhere else, which is a different attack with a similar outcome.

Partly, and the part matters. Change detection on your own HTML and your HTTP headers is real 11.6.1 value and a CDN is well placed to do it. What it misses is the larger half: third-party script payloads that change without your origin response changing at all.

No. Cloudflare is a PCI DSS compliant service provider and provides controls that map onto specific requirements, particularly TLS in requirement 4 and the WAF in 6.4.1. Compliance is assessed against your cardholder data environment, so their attestation goes on your file and your own assessment still happens.

No, not on its own, though it produces the right kind of material. What you have at the end is an authorisation-grade justification and an integrity record for one script at one moment. Both requirements are continuous: 6.4.3 covers every script on the payment page with a justification and an integrity method, and 11.6.1 requires change detection on the page and its HTTP headers at least every seven days. Doing this by hand for one script does not scale to either.

No. Both are client-side controls concerned with code executing in the browser. Server-side attacks need server-side controls, and a WAF, patching and access control are not replaced by either of these.

No. There are legitimate if uncommon uses, and it is a strong signal in combination with others. A script on a payment page assembling code from encoded strings and passing it to eval deserves attention regardless of its origin.

No. Any form worth stealing from can be targeted: logins, insurance quotes, patient intake, account registration. Payment forms attract the most attention because card data has immediate resale value.

No, and that is what makes it difficult. The usual route is a compromised third-party script or tag manager, so your own infrastructure is untouched and your logs show nothing.

No. HTTPS protects data in transit between browser and server. A skimmer operates inside the browser after decryption, and it will happily send stolen data over HTTPS as well.

No, not for the client-side security product. They have historically offered trials, which is a different thing from a permanent free plan.

No. Like almost every vendor in this category, pricing is by quote. We have not seen a public figure we would trust enough to repeat.

Yes, mainly in who runs the infrastructure. Adobe Commerce on cloud infrastructure shifts some hosting and patching responsibility. The application and client-side layers are the same in both.

No, and conflating them wastes a lot of time. Minification shortens names and removes whitespace to reduce file size, and it leaves readable string literals, URLs and error messages behind. Obfuscation deliberately removes meaning: encoded strings, array indirection, flattened control flow. Nearly every legitimate vendor tag is minified. Relatively few are obfuscated.

Yes, somewhat. Obfuscated code is larger and often slower to execute, because the indirection and dead code have a runtime cost. For an attacker that is an acceptable trade, and for your own code it is a real one to weigh.

Sometimes, and it is worth asking early. Assessors see many implementations and often have clear views on what produces acceptable evidence. That conversation is cheaper before you buy than after.

No. A container shows what is configured in it. It does not show what those tags loaded afterwards, nor anything injected outside the container, which includes anything an attacker added.

Yes, substantially, because it shifts trust from the address to the content. If you pin the payload you approved, a script served from a lookalike domain is a payload you never approved.

Yes, and it is the only lever that changes the order of magnitude rather than the margin. Every system removed from the cardholder data environment is a system that does not need assessing, hardening, logging or monitoring.

Partly, and conditionally. The January 2025 update exempted eligible SAQ A merchants from certain requirements including these two, provided you confirm your site is not susceptible to attacks from scripts that could affect your ecommerce systems.

No. Shopify is compliant as a service provider, which covers its infrastructure and payment handling. Your own obligations cover what you add: apps, theme code, tags and admin access.

Partly. It protects against the file changing after you pinned it, which covers a compromised CDN. It does nothing about a vendor whose script was malicious at the moment you generated the hash.

Partly. It addresses the integrity assurance element well, for the scripts you can apply it to. It does not produce the inventory or the written business justification per script, which are the other two elements of the requirement.

Partly. The integrity property can be set when creating a script element programmatically, and any script injected by a third party at runtime is outside your control entirely, which is where most of the risk sits.

Partly, and it is rarely practical for tags. SRI pins the exact contents of a file, which is exactly the right idea. It breaks whenever a vendor legitimately updates their script, which is why almost nobody runs it on third-party tags in production.

No. 6.4.3 asks you to inventory the scripts on your payment page, authorise each one and justify it in writing, with a method for assuring integrity. A WAF inspects traffic in transit and cannot see what a script does in the browser or that a trusted vendor shipped altered code at an unchanged URL.

No. PCI DSS SAQ D merchants and service providers are in scope for 6.4.3 and 11.6.1 in full, with no carve-out of any kind. SAQ D is the full questionnaire and the client-side requirements are part of it.

Yes. 6.4.3 covers all scripts loaded and executed in the consumer's browser on a payment page, which includes your own. Your own code is usually the easiest to justify, so it is quick work.

Yes, in the sense that the same logic applies: if the customer ends up typing their card on a page you serve, that page is in scope. If they type it on your provider's page, it is not.

Yes, as part of 6.4.3. An inventory that records origins by eye can record the wrong origin. Comparing by value and pinning by payload hash is what makes the inventory trustworthy.

Partly. Tokenisation protects the card after your provider receives it. A skimmer reads the value as the customer types, before tokenisation happens, so it does not prevent the theft.

Partly. React, Vue and Angular escape output by default, which removes most classic XSS. They do nothing about third-party scripts you load deliberately, because those run exactly as intended.

Yes, if it keeps card data off your servers by using a hosted form or iframe. It does not remove the checkout page itself from scope, because that is where a script would sit.

No, it reduces scope rather than conferring compliance. Card data stays off your systems, which removes a great deal from your cardholder data environment. Your remaining obligations, including the client-side requirements on the page hosting the iframe, still apply.

No, though it reduces your scope substantially. Using a compliant provider means card data is handled by systems you do not run. Your own obligations do not disappear, and the client-side requirements are a good example: the page hosting your provider's iframe is still yours and still in scope.

No material change to the segmentation requirements themselves. What changed more broadly is the expectation of documented scoping: v4.0 is more explicit about confirming scope at least annually and documenting how you determined it.

They are a common gap. Agency accounts frequently retain publish rights long after an engagement ends. Quarterly access review usually finds several.

Deliberately and effectively: firing only on checkout URLs, only for certain card BIN ranges, only for a fraction of visitors, never for the same visitor twice, and never when the browser appears automated. Payloads are also usually obfuscated.

Usually through resale rather than direct use. Harvested card data is sold in bulk on criminal marketplaces, often batched by issuing bank and card type, which is also why BIN-range filtering appears in skimmer code.

That message means the browser blocked something your policy does not permit. Either add the origin to the relevant directive if it is legitimate, or investigate why it is loading if it is not. Do not reach for 'unsafe-inline' as the fix unless you understand what you are giving up.

Two passes. Review the access list and remove everyone who does not need publish rights. Then compare what the container claims to publish against what actually executes on the page, because the two diverge more often than teams expect.

Programmatically: check every entry for mixed-script characters and for any non-ASCII code point. Legitimate entries almost never contain them, so the false positive rate is very low.

With a record showing the evaluation frequency and the results per period. If you monitor continuously, say so and show the evidence; you comfortably exceed the floor and do not need a targeted risk analysis to justify a longer interval.

By recording what actually executes in real sessions. The extension list shows what is installed, not what each extension loads at runtime, and the gap between those two is where the surprises are.

By recording what actually executed rather than what you configured. The call stack at load time names the script that triggered each load, which is what lets you reconstruct the chain rather than guess at it.

This is the common difficulty, and it is a scoping problem more than a policy problem. The usual answer is to reduce the set first, especially on payment pages, then write the policy against what remains. Writing a policy around an unreviewed tag set produces a permissive policy.

There is a middle path that usually survives the conversation: keep the script and remove one capability, such as reading form fields. It is a smaller and more defensible action than removing the vendor entirely.

The deciding question is whether your website can affect the security of the payment transaction. A full redirect to a provider-hosted page usually means SAQ A. An embedded provider iframe can also be SAQ A, provided you meet the script eligibility criterion that PCI SSC FAQ 1588 explains. Payment fields or scripts served from your own site usually mean A-EP. Confirm with your acquirer, because they set the requirement.

By looking at what actually executes rather than at the app list. Many apps inject more than their description implies, and some load third-party code of their own.

By selector rules covering the pages that embed it. Page views on those pages count towards your plan, and the rest of your site does not.

Two mechanisms: Subresource Integrity if the file is versioned and stable, and payload monitoring if it is a vendor tag that updates. Pin the contents one way or the other.

With a default-deny posture and a weekly queue. If new scripts arrive in a 'requires action' state and someone reviews the change list weekly, accumulation stops being silent.

This is the hard case. Environment checks mean dynamic analysis reveals nothing, so static analysis does the work, along with observing the script in genuine sessions where the conditions it requires are actually met.

Hard to answer usefully, because almost all the alternatives are also quote-based. The two published points of reference in this category are ours and Report URI, which does something narrower.

Directly. 6.4.3 requires a written business justification for every script on a payment page. Shadow code is the set of scripts with no justification, so it converts straight into findings.

By passing the data through: the attacker's form collects the details, then submits them to the real endpoint so the purchase completes and the customer receives their order. Nothing appears wrong from the customer's side.

A matter of emphasis. Formjacking names the mechanism, hijacking the form itself. Web skimming names the outcome, copying the card. Most formjacking is web skimming and the terms are used interchangeably.

Typically far too long: weeks to months is common, because nothing visibly breaks. Many merchants learn about it from an acquirer raising a common point of purchase rather than from their own monitoring.

The technical part is fast: a tag goes in and the inventory populates from live traffic within days. The slower part is organisational, collecting a written justification from the owner of each script, which for a busy checkout can take a few weeks of chasing.

It varies by architecture: a tag-based tool is minutes to install and days to tune. A sandbox needs configuration per vendor script. A network-layer product needs a routing change. Scanners are fastest to start and weakest in coverage.

Budget for a sales cycle rather than an afternoon: typically a discovery call, often a technical session, then a proposal. For a category where you may want to compare three vendors, that is real time.

It is usually shorter than expected. A commonly obfuscated sample takes one to three hours to get to the point where the five questions are answered, and most of that is step 2. A sample with layered anti-analysis and a second stage that only loads under the right conditions can take a day or more, which is the point at which runtime observation earns its place over static work.

It varies with scope, and the honest answer is that we are not the right source for a number. It depends on the size of your cardholder data environment, the number of locations and systems, and how much remediation is needed. Get two or three quotes, because they differ widely for the same scope.

It varies enormously with scope, from a few thousand for a small SAQ A merchant to six figures for a Level 1 assessment with remediation. The client-side line item is usually one of the smaller ones. We break it down in PCI compliance cost.

More than teams expect, and the count matters less than the depth. The consistent finding is scripts two and three links away from anything anyone approved. We would rather you measure your own than quote an industry figure at you.

It is usually one of the smaller line items. Ours is published at $99/month for 100,000 payment-page views. Most competitors are quote-based, so build a sales cycle into your timeline.

More than you think, and this is the line most often missed. Evidence collection, questionnaire completion, coordinating across teams and chasing script owners for justifications all take real time from people who have other jobs.

Annually as a baseline, with quarterly vulnerability scans by an Approved Scanning Vendor where applicable. Several v4.0 requirements also carry their own frequencies, and 11.6.1 is one: at least once every seven days, or a frequency justified by a targeted risk analysis under 12.3.1.

Weekly is the practical rhythm if the review surfaces only changes. Annually is what happens when the review surfaces everything, and annual review is how inventories drift out of date.

Quickly, which is part of the problem. Skimmer kits are sold ready to configure, so the time between compromising a script and collecting card data can be minutes.

By comparing against a baseline: a script executing that is not in your inventory, an approved script whose payload hash changed, or a script contacting a destination it has never used. Without a baseline there is nothing to compare against.

Partly, and it is a trade-off worth making consciously rather than by accident. It is extremely common because removing inline script from a legacy application is expensive. A policy with it still restricts external origins, which is worth something, and it no longer meaningfully protects against injected inline script.

No, not by name. PCI DSS 6.4.3 and 11.6.1 describe outcomes rather than mandating a specific technology. A CSP contributes to meeting them and does not satisfy either on its own.

Yes, a strong one. If a script you approved was readable and its new version is obfuscated, that is worth investigating regardless of what the code does, because legitimate vendors rarely make that change quietly.

Sometimes, and it is the question to settle before buying. Some assessors accept scanning; others do not accept a control that cannot block. Ask yours directly rather than discovering it at assessment.

Partly. The inventory itself can be a spreadsheet. The integrity assurance half of 6.4.3 is the problem, because a static document cannot detect that a vendor changed their payload.

Sometimes, and it is weaker than it sounds. A scan from datacentre infrastructure with no session and no cart is exactly the visitor a targeted payload ignores, and between scans there is no coverage at all.

No. Adobe Commerce is software, and the managed cloud offering shifts some infrastructure responsibility. Configuration, extensions, custom code and everything executing on your checkout stay yours.

Yes, it is the attack requirements 6.4.3 and 11.6.1 were written to address. 6.4.3 asks you to know and authorise every script on the page; 11.6.1 asks you to detect when the page changes.

Yes in practice. Formjacking is the mechanism and Magecart names the groups who use it. An incident described as Magecart is almost always formjacking underneath.

Partly. Free tiers exist, including ours at 1,000 page views a month, and they are genuinely useful for evaluation and for very small stores. A full GRC platform at zero cost is not something we have seen work.

Yes, as a platform. The risk is not in the platform's security, it is in how it is configured and who has access. The same is true of Adobe and Tealium.

Partly. Inline script is not inherently malicious, and it complicates defence: it has no URL to allowlist and no external file to hash, so identifying it requires hashing the inline content or using nonces.

Yes, in the ordinary case. Analysing code that was served to your own website, on your own systems, is routine defensive security work and is what incident response consists of. Two caveats worth knowing: a vendor contract may contain a reverse-engineering clause, which is a commercial question rather than a legal barrier to inspecting what runs on your page, and none of this is about circumventing access controls or licensing. If the script is unattributed, no contract applies.

No. The language is not the problem. The issue is the execution model: a page runs code from several sources with no privilege separation between them, so the least trustworthy script has the same access as the most trustworthy.

No, XSS is one route among several. Cross-site scripting specifically means an application flaw allowing input to be rendered as executable code. JavaScript injection is the broader outcome, and on payment pages the more common route is a compromised third-party script rather than a flaw in your own application.

Yes and no, and honestly we cannot tell you. It is enterprise software sold by quote, so the answer depends on your scope and your negotiation. What we can say is that a free tier is not part of the model.

Yes to both, which is why the term is confusing. It began as a name for specific groups targeting Magento stores and is now used loosely for the whole category of browser-based card skimming. Researchers track numbered groups with distinct tooling, but there is no single Magecart organisation.

No, not any more. The name is historical. The technique works against any checkout that loads third-party JavaScript, which is nearly all of them, on every major ecommerce platform.

Yes. The tooling, hosting and evasion techniques have evolved, and the underlying economics have not changed: checkout pages load third-party code, third parties get compromised, and card data has resale value.

Yes, and no more than other platforms now. The technique spread everywhere years ago. What remains specific to Magento is the size of the extension surface on a typical store.

No, not automatically, but it is a reason to require a justification. Some legitimate vendors obfuscate anti-fraud logic on purpose, and that is a defensible answer if they give it. What is not defensible is a script on a payment page that nobody can attribute and that has been deliberately made unreadable. PCI DSS 6.4.3 asks for a written justification per script, and "we do not know what this is" does not satisfy it.

No, and the distinction matters. Encrypted code cannot run without a key. Obfuscated code runs directly, so everything needed to understand it is present in the file. It raises effort, not a barrier.

No. Minification removes whitespace and shortens names to reduce file size, and it is reversible enough that the logic remains clear. Obfuscation deliberately makes the logic hard to follow, and that is its purpose rather than a side effect.

It can be, and that is a genuine answer rather than a hedge. Confirm three things first: that it is switched on, which capabilities your plan actually includes today, and whether the evidence it produces is an export your assessor will accept rather than a dashboard you screenshot.

Yes, usually substantially. Outsourcing card handling removes systems from scope, which can move you to a shorter questionnaire and reduce the assessment surface. It does not remove your obligations entirely, and the client-side requirements are a good example of one that remains.

Partly, and it depends on your SAQ. A small SAQ A merchant may need very little tooling. Once you are on SAQ A-EP or SAQ D, the client-side requirements apply in full and a spreadsheet stops being sufficient because it cannot detect change.

No to the first, yes to the second. Credit card compliance is the everyday name for what the card brands require of anyone handling card data, and PCI DSS is the standard behind it, so the two phrases mean the same thing in practice. It is not law. PCI DSS is enforced through your agreements with your acquirer and the card brands rather than by statute. In practice the distinction rarely helps you: non-compliance can mean fines passed down by your acquirer, higher transaction costs, or losing the ability to accept cards, and after a breach it affects your liability position significantly.

No. Software produces controls and evidence; compliance is a judgement made across the whole standard by your assessor or by you on an SAQ. Be specific about what any tool covers: a client-side tool covers two requirements out of twelve families, and a GRC platform tracks evidence without producing the technical control itself.

No, it is the norm in enterprise security software and reflects genuine variation in deployment scope. It is a cost in evaluation time rather than a warning sign.

No, and it usually is not. Most of it is forgotten rather than hostile. The risk is that it is unmanaged: nobody is watching whether it changed, and nobody would notice if it did.

Yes, generally more of this is yours. Plus offers greater checkout customisation, and more customisation means more of your own code near the payment step and a larger 6.4.3 scope.

No, they answer different questions. A CSP controls which origins may load resources. SRI verifies that a specific file is the file you expected. Running both is sensible where both are practical.

Sometimes, and the thing to check is whether it produces what your assessor will accept. A scanner is usually cheaper than session-level monitoring, and some assessors do not accept a control that cannot block. Buying something your assessor rejects is the expensive outcome.

Yes. It is a page where a cardholder enters card data, and it is where a malicious script would run. The iframe belongs to your provider; the page around it is yours.

Yes for now, and worth watching. It was introduced in January 2025 and reflects a judgement about relative risk for the least exposed merchants. Standards change, and the direction of travel on client-side risk has been one way for several years.

Yes: look for scripts on payment pages that read form fields or contact destinations not in your approved list. That intersection is small and it is where the genuine problems concentrate.

Yes, most commonly in phishing, and it appears in script supply chain incidents where a lookalike CDN domain is used to make injected code look routine to anyone reviewing the page.

Yes, but only as a clarification. v4.0.1 corrects errors and clarifies intent without adding new requirements. If you were working towards v4.0 you are working towards v4.0.1.

Yes in practice, with a technical distinction. Web skimming is the technique; Magecart refers to the groups who use it. A vendor offering Magecart protection and one offering web skimming protection are describing the same capability.

No, and neither does the iframe. The iframe is your provider's, the page hosting it is yours, and a script on that page can overlay it or capture keystrokes before it. See hosted payment pages and PCI.

Yes, in our view, and we will declare the bias: we sell this. The stronger argument is the confirmation itself. You are asserting your site is not susceptible to script attacks, and the cheapest way to make that assertion honestly is to know what scripts are running.

Yes, prefer the header. A meta tag works and cannot express certain directives, including frame-ancestors and report-uri, and it applies later in parsing, so some content may already have loaded.

Partly, and only if you need both. If your driver is PCI DSS 6.4.3 and 11.6.1 you may only need the client-side product. Ask for that price separately so you can see what the bundle is costing you.

No, not as a security control. Minification is a performance measure. Obfuscation raises the effort for a casual reader and does not prevent determined analysis, because the code has to execute in an environment the attacker controls.

Sometimes, and it is a real trade-off rather than an obvious win. A redirect reduces scope more, and it usually costs conversion, because customers leave your site at the moment of payment. That is a commercial decision rather than a security one.

Partly, depending on why. It is reasonable for protecting business logic from casual copying. It is not a security control, and it should never be the thing standing between an attacker and something that matters.

Yes, if you are on an unsupported version. Running software that no longer receives security patches is difficult to defend to an assessor and is how a large share of historical compromises happened.

Partly, and it is a real trade-off. The safest position is no container on the checkout, which many organisations find operationally impossible. The workable middle ground is a separate, tightly controlled container for payment pages with a short publish list and an approval step.

Sometimes, and it is genuinely contested. Your page runs JavaScript alongside the iframe and that script can overlay it or capture keystrokes before the iframe receives them. Whether that counts as affecting the security of the transaction is a question for your assessor, and many land on A-EP.

No, just a clearer one. A CDN without a client-side product simply does not address 6.4.3 or 11.6.1, which is easier to reason about than a half-configured one. Nothing about your CDN choice makes the requirements harder.

It deserves more attention than it gets. A container is designed to inject arbitrary JavaScript, so access to it is equivalent to the ability to deploy code, without any of the review that real deploys go through. See tag manager security.

They count, and they need an identity of their own since they have no URL. Hashing the inline content is the usual approach. Injected inline scripts are also a common attack shape, so they are worth attention rather than exclusion.

They count too. Anything that executes in the customer's browser on a payment page is in scope for 6.4.3, regardless of who injected it or at what layer.

Where it is practical. SRI pins the exact contents of a file and is excellent for static assets you control. It breaks when a third party legitimately updates their script, which is why it is rarely used on vendor tags.

Worth checking. It often carries more third-party scripts than the checkout itself because merchants add marketing and analytics there, and whether it is in scope depends on whether card data is displayed or entered.

These are the two client-side requirements and the newest part of the standard. 6.4.3 requires you to inventory and authorise every script on your payment pages and assure each one's integrity. 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorised changes to payment page content and HTTP headers, at least every seven days.

Typically everything useful on the page: name, billing address, email, phone and sometimes account credentials. Full identity sets are worth more than card numbers alone.

Ours is published: free for 1,000 page views a month, from $99/month for 100,000 payment-page views, $499/month at 500,000, $799/month at 1,000,000, overage at $0.0013 per page view. Most vendors in this category do not publish figures, so comparing requires a sales cycle.

In our experience four things: the documented payment-page scope, the script inventory with a justification per script, the record of header and content changes with timestamps, and evidence that personnel were alerted. Prepare those four and most of the conversation is straightforward.

They test it: they will look for a justification per script, check that it is current against what is actually on the page, and ask how you would know if a script changed. An inventory that does not match live reality is the common finding.

This is where it gets expensive. A forensic investigation determines compliance status at the time of the breach. Being found non-compliant typically means assessment fees, fines passed through your acquirer, card reissuance costs and a move to a stricter validation level, in addition to the direct costs of the incident.

This is worth handling directly rather than hoping. The requirements are mandatory, so an assessment will find them open. Assessors generally respond better to a documented remediation plan with dates than to a gap with no plan attached, and the client-side pair is among the faster gaps to close.

The browser refuses to execute the resource entirely. There is no warning-only mode and no partial execution. On a payment page that can mean a broken checkout.

It still belongs in the inventory, and it is often the interesting one. A script appearing in a small share of sessions is exactly what a targeted payload looks like.

This happens, and it is informative in itself. You still have to write a justification, and if the vendor cannot support one, that is an argument for removing the script from the payment page specifically rather than from the site.

This is very common, and it means your policy provides much less XSS protection than it appears to. It still restricts external origins, which is worth something. It also makes monitoring more valuable, because injected inline script is exactly what you are no longer blocking.

That happens, and it is a known evasion rather than a reason to close the ticket. Payloads gate on the Referer, the visitor's country, the user agent, a fraction of requests, or the time of day. Fetch several times from conditions that resemble a real visit, compare hashes across those fetches, and treat a file that differs between two fetches minutes apart as the finding itself.

This does happen, and the inventory is often how it is found. Treat it as an incident: preserve the payload as evidence, determine the exposure window from your records, and follow your incident response and breach notification obligations. Do not simply delete it, because the payload is what tells you what it collected.

It is an allowlist enforced by the browser. You send a header listing which sources of scripts, styles and other content are permitted, and the browser refuses to load anything you did not list.

A documented analysis under requirement 12.3.1 justifying the frequency at which you perform a given activity. Several v4.0 requirements permit a self-defined frequency if you produce one. It has specified elements it must cover and it is reviewed by your assessor.

One of the more effective techniques: the code's logic is rewritten into a single dispatch loop over a state machine, so the sequence of operations is no longer visible in the structure of the source.

Record the payload hash observed in production and treat a change as a review item rather than a block. You get the integrity assurance 6.4.3 asks for, and a vendor update becomes a decision instead of an outage.

There is an honest answer and it is not a single product. It depends on whether you can add a tag, whether you already pay for a CDN that bundles a module, and whether your assessor accepts a control that cannot block. Those three questions eliminate most of the list.

With a caveat: it depends which category you need. For tracking evidence across all twelve requirement families you want a full-scope GRC platform. For the technical control on payment pages required by 6.4.3 and 11.6.1 you want a client-side tool. Most organisations past a certain size use both.

A compromised third-party script, by some distance. It requires no flaw in your own code, arrives through a channel you deliberately opened, and passes both your CSP and your allowlist.

A useful distinction. A typosquat relies on a human making a typing mistake, so the domain is genuinely different and looks different. A homoglyph looks identical, so no mistake is required by the victim at all.

They are complementary. A CSP controls which origins may load resources. SRI pins the exact contents of a specific file by hash. CSP asks where it came from; SRI asks whether it is the file you expected. See Subresource Integrity.

Mostly a matter of granularity. Hosted fields put individual provider-controlled inputs inside your own form, so more of your own markup and code sits adjacent to the card entry point. The scope consequence is broadly similar to an iframe.

An important one for rollout. Content-Security-Policy-Report-Only sends violation reports without blocking anything, so you can see what a policy would break before it breaks it. The enforcing header blocks. Always start with report-only.

It catches people out. SAQ A is for merchants who have fully outsourced payment handling and whose site cannot affect the payment transaction. SAQ A-EP is for ecommerce merchants who never receive card data but whose website can affect the security of the payment page, which is the case for most sites embedding a payment iframe or redirecting after collecting order details.

Build an inventory. You cannot detect an unexpected script without a definition of expected, which is also why PCI DSS 6.4.3 asks for one before anything else.

This is the main mechanism: Custom HTML permits arbitrary script. Most legitimate tags do not need it, so restricting who can create one narrows the risk substantially without much friction.

Unpatched software combined with an unreviewed extension set. Those two account for most historical compromises, and both are addressable without much cost.

It is unglamorous: remove scripts from the payment page that nobody can justify. It is the only control that shrinks the attack surface instead of observing it, and 6.4.3 makes you do the analysis anyway.

Four questions that separate products quickly: does it observe real sessions or scheduled scans, can it block or only report, does it keep 6.4.3 and 11.6.1 as separate records, and what is metered. Then ask to see an actual evidence pack rather than a dashboard.

Four things, and get them in writing: whether Page Shield is active on the zones serving payment pages, which capabilities the current plan includes, what proportion of sessions are observed, and what the evidence export contains. Those four answers decide whether anything else is needed.

Several things that matter more: coverage model, whether it can block or only report, whether the 6.4.3 and 11.6.1 evidence is separated the way assessors ask, deployment effort in engineering days, and what the assessor actually receives.

Inventory. Every defence listed here depends on knowing what is supposed to be executing, and that is also what PCI DSS 6.4.3 asks for first.

Treat it as an incident rather than a cleanup task. Preserve the payload as evidence before removing it, because it tells you what was collected and where it went. Determine the exposure window from your records, then follow your incident response and notification obligations.

Treat it as an incident. A homoglyph domain in your script origins or your CSP is not an accident, so preserve the evidence, establish when the entry was added and by whom, and check what loaded from it while it was there.

Blocking, at whichever granularity fits: the whole script by URL or hash, the whole origin by domain, or just the capability to read form fields if you need the script to keep working.

Less than you would think: a browser with developer tools, a code formatter, a JavaScript runtime you can run offline in a throwaway container, and optionally a syntax-tree tool for the substitution step. Everything in this post is done with those. The expensive part is never the tooling, it is having the original bytes and a previous hash to compare against.

V4.0.1, published in June 2024. It is a clarification of v4.0 rather than a new set of obligations. The important date was 31 March 2025, when the future-dated requirements from v4.0, including 6.4.3 and 11.6.1, became mandatory.

V4.0.1 was published in June 2024, and the date that carries the obligations is 31 March 2025, when the future-dated requirements from v4.0 became mandatory. Both dates have passed.

From the source: the PCI Security Standards Council publishes PCI DSS v4.0.1 and its supporting guidance in the document library on their site. We would always recommend reading the requirement text directly rather than relying on any vendor's summary, including ours.

Cloudflare has published it since March 2026, when Page Shield was renamed Client-Side Security. The base tier is on every plan, and Client-Side Security Advanced, the tier with code change detection, is $0.099 per 1,000 requests, self-serve. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.

In the SAQ A document itself and the accompanying summary of changes published by the PCI Security Standards Council in January 2025. Read the source rather than a vendor summary, including this one.

With the checkout, not the whole site. Inventory what executes there, delete what has no owner, add a CSP in report-only, then enforce. That sequence gets most of the benefit in a few days.

Sha384 is the common choice and sha256 and sha512 are also supported. You can supply multiple hashes, and the browser accepts the resource if any one matches, which is useful during a planned transition.

Only a few: ours, Report URI, DomDog and Source Defense. The rest are quote-based, which makes genuine comparison slow and expensive and is worth factoring into your evaluation timeline.

Very few in the client-side category: ours and Report URI. GRC platforms more often publish at least a starting price.

Third-party compromise, by some distance. It requires no flaw in your code, uses a channel you deliberately opened, and passes both your allowlist and your policy.

Commonly SAQ A-EP rather than SAQ A, because your website can affect the security of the payment transaction. It is contested in places, so confirm with your acquirer.

Commonly SAQ A for a full redirect, or for an embedded provider iframe that meets the script criterion in PCI SSC FAQ 1588. SAQ A-EP where your own site serves the payment fields or scripts that affect them, and SAQ D for stores handling card data directly. A-EP carries 6.4.3 and 11.6.1 in full. Confirm with your acquirer.

Commonly SAQ A, and it depends on your configuration and your acquirer. Stores using Shopify Payments with the standard checkout are usually at the simpler end. Custom checkout or extensive checkout extensions can change that, so confirm rather than assume.

The order matters: inventory first, then the CSP. Writing a policy without knowing what currently executes produces either a broken site or a permissive policy, and the permissive policy is the more common outcome.

Several make validation claims and the two we can speak to directly are Source Defense and ourselves. Ask any vendor for specifics rather than accepting the phrase, because it is used loosely.

A substantial set, including 6.4.3 and 11.6.1 for payment-page scripts, expanded MFA under requirement 8, several logging and monitoring provisions, and a number of requirements carrying targeted risk analyses. All became mandatory on 31 March 2025.

Uncomfortably, largely you. You chose to install it on your store. The app developer has obligations too, and your acquirer's relationship is with you, which is why reviewing what apps do on checkout matters.

Naming someone is usually the hard part. The scripts are added by marketing, the page belongs to engineering or ecommerce, and the risk lands on security. Without a named owner the queue does not get worked.

Naming an owner is often the first real step, because ambiguity is the usual failure mode. The scripts are added by marketing, the page belongs to ecommerce or web engineering, and the risk lands on security or compliance. Someone has to own the queue.

This is the central practical problem: the vendor changes the file contents whenever they deploy, without notifying you. The next deploy breaks your hash and the script stops loading.

There are real reasons alongside the commercial ones: deployments vary substantially in scope, enterprise buyers often negotiate anyway, and quoting lets vendors price to value. It also makes comparison slow, which is not accidental.

Partly right, and worth doing carefully. Some unrecognised scripts are load-bearing for something unexpected, such as fraud scoring or accessibility. Run in monitor-only first so you can see what would break before it does.

A fair question, and the honest answer is: verify it. We have stated our bias, given every competitor real strengths, named the situations where they beat us, and published our pricing so the one claim we rank ourselves on is checkable. Read the sections for the products closest to your constraints rather than the one at the top.

No, not on the basis of obfuscation. A CSP is an origin allowlist: it decides where a script may load from, never what a script does once it is allowed. An obfuscated payload served from a vendor you already allow passes the policy cleanly, which is exactly the case that matters on a payment page. See Content Security Policy.

Partly, and only if the policy is right. A CSP allows specific origins by exact value, so a lookalike domain is not permitted unless it was added to the policy. The risk is an attacker adding it to the policy, where it passes visual review.

Partly, and it raises the cost. Client-side encryption of field values means a listener captures ciphertext rather than a card number. A script that replaces the form controls the encryption step too, so it is not a complete answer.

No. A web application firewall inspects traffic arriving at your application. A skimmer reads the card in the browser and posts it from the browser to the attacker, so that traffic never reaches your infrastructure and there is nothing to inspect.

Partly, from the container's own version history, which is useful if the attacker did not also have the ability to alter it. Monitoring the page is the more reliable answer, because it observes the outcome regardless of how it was introduced.

No. The request goes from the customer's browser to the attacker's server and never traverses your network, so it does not appear in your logs at all.