The skimmer doesn’t go inside the iframe. It doesn’t need to.
In every significant payment page compromise of the last decade, the malicious code sat on the merchant’s page, outside the payment component entirely, watching form submissions, intercepting keystrokes, reading values before they ever reached the provider’s sandbox.
This is the architecture SAQ A-EP merchants live in. It is genuinely more secure than one where a merchant’s own server handles raw card numbers, and that is not in dispute. What is in dispute is whether the page the browser assembles around that payment component is held to any standard at all.
PCI DSS v4.x answers that question with two requirements that most teams shipping hosted payment pages have either misread, underestimated, or haven’t found yet. Requirement 6.4.3 covers every script that executes in the consumer’s browser on a payment page. Requirement 11.6.1 covers the ongoing watch for tampering with those scripts and security headers, not at deployment, but as customers experience them.
What you’ll learn:
- Exactly which pages fall into SAQ A-EP scope in real-world hosted payment architectures (iframe embeds, redirect initiators, pure redirects, and SPAs), and why “the iframe is the boundary” is a false assumption.
- What PCI DSS v4.x Requirements 6.4.3 and 11.6.1 actually require on those pages: a defensible script inventory with justification and ownership, auditable authorization, integrity assurance for approved scripts, and tamper/change detection for scripts plus security-impacting headers as the browser receives them.
- How to operationalize those controls without relying on point-in-time checklists: what to monitor (including tag-manager/dynamically injected scripts), how to reduce script surface area, what “weekly minimum vs continuous” means in practice, and what evidence a QSA will expect to see.
Which pages are actually yours to own
SAQ A-EP’s premise is simple and uncomfortable: your website can affect the security of a payment transaction even when your servers never see a card number. PCI DSS scope reaches any system component that could impact the security of cardholder data, which includes payment pages and the parent pages that embed them. Treat any page that touches the payment journey in the browser as potentially in scope.
In practice, that means four categories of pages require explicit consideration.
Checkout pages embedding hosted payment fields. Stripe Elements drops into your form as an iframe. Braintree Hosted Fields renders custom iframes directly onto your checkout page. The provider owns what’s inside the iframe. You own every script on the page surrounding it.
Pages that initiate a redirect to a hosted payment page. Redirects can be implemented server-side, via HTML tags, or via JavaScript. When scripts are involved in that redirect mechanism, Requirements 6.4.3 and 11.6.1 follow those scripts.
Pure redirects with zero client-side logic. Under the 2025 PCI SSC clarifications, “pure” means the redirect happens via a server-side 302 header or a static HTML link. If your redirect is triggered by a JavaScript window.location call or a “Pay Now” button managed by a script, that script is in scope for 6.4.3. Most modern “redirects” are actually script-driven, meaning they rarely qualify for the carve-out.
Single-page applications (SPAs) create a “persistent” scope. In a traditional multi-page site, navigating to a new URL flushes the browser memory. In an SPA, a malicious script loaded on the “Home” or “Gallery” route remains active and resident in memory when the user reaches the “Checkout” component. Because the DOM never resets, every script loaded since the landing page is technically “on the payment page” and must be inventoried and monitored.
What all of these page types have in common is scripts. And once you know which pages you own, the question that follows is unavoidable: what, exactly, are you required to do about every script running on them.
Requirement 6.4.3: You own the scripts on the page you built
6.4.3 requires every script loaded and executed in the consumer’s browser on a payment page to be managed through three controls: an inventory with written justification for each script, a provable method confirming each script belongs there, and integrity assurance that approved scripts have not been modified. The objective is equally direct. Unauthorised code cannot execute in the payment page as the consumer’s browser renders it.
The compliance trap for SAQ A-EP merchants is assuming the iframe is the payment page and therefore the provider’s problem. PCI guidance draws the responsibility split clearly. The TPSP owns scripts inside the iframe. You own every script on the page that embeds it. Attackers have compromised checkout experiences built around PCI-compliant payment iframes precisely because the surrounding page had no controls in place.
What inventory, authorisation, and integrity actually demand
Your script inventory must reflect what executes in the browser, not what your repository declares. Tag managers, marketing pixels, A/B tooling, chat widgets, any third-party loader that pulls in additional code at runtime: all of it counts. PCI guidance warns explicitly that scripts can have their functionality altered without the entity’s knowledge and can load additional external scripts that are then abused for skimming.
Authorisation must be auditable. Each script needs a named business owner who requested it, a security review, and documented justification for why it belongs on a payment-affecting page. PCI guidance does not prescribe the format: simple environments may use a spreadsheet, while complex environments typically require automated tools or workflow systems. What it does require is that the approval trail exists and can be shown to a QSA.
Integrity must demonstrate that approved scripts have not changed. PCI guidance does not mandate a single technique, pointing to Content Security Policy, Subresource Integrity, file hashing, and behaviour monitoring as recognised approaches. For static third-party scripts, SRI is a practical starting point:
<script src=”https://example-cdn.com/library.min.js”
integrity=”sha384-BASE64HASH”
crossorigin=”anonymous”></script>
PCI DSS does not require SRI specifically. It requires you to demonstrate integrity. How you do that is yours to decide and your QSA’s to validate.
The controls are straightforward. Your checkout page is not.
Tag managers inject scripts at runtime. Marketing teams add pixels without telling engineering. A/B testing platforms load third-party code based on audience segments. Every one of these is a potential vector, and none of them appear in your repo. Your integrity controls need to account for what the browser actually receives, not what you shipped.
Match your integrity control to how the script actually arrives
Static third-party libraries suit SRI. First-party scripts can be controlled through build pipelines with hash-based integrity checks. Dynamically injected scripts require runtime monitoring because the control objective is what the consumer’s browser receives, not what you reviewed in staging.
Scope minimisation is the control most teams skip and the one PCI guidance is most direct about. Limit scripts on payment pages to those strictly necessary. Move non-essential scripts to sandboxed iframes where possible. Use CSP’s script-src to constrain where scripts can load from. Baseline script behaviour and run periodic or continuous assessments of anything third-party. The fewer scripts on the page, the smaller the surface you are committing to inventory, authorise, and monitor indefinitely.
Governing the state of the page solves for today. It does not solve for the change someone makes at 2am that nobody authorised, or the third-party script that quietly updates itself between your weekly reviews.
Now watch for changes
If 6.4.3 is about governing the state of the page, 11.6.1 is about catching when that state changes without your knowledge. It requires a change and tamper-detection mechanism that evaluates security-impacting HTTP headers and script contents of payment pages as the consumer browser receives them, with alerts going to personnel at least weekly, or at a frequency your targeted risk analysis justifies.
The threat model behind 11.6.1 is specific. Attackers increasingly favour stealth. A skimmer that breaks your checkout is discovered quickly. A skimmer that lets the checkout succeed while quietly copying card data can persist for weeks. The requirement exists because you cannot rely on customer complaints or failed transactions to tell you something is wrong.
Continuous monitoring versus the weekly minimum
Weekly is the floor, not the target. The PCI SSC’s own guidance on e-skimming notes that these attacks are difficult to detect as environments grow more complex and reliant on external scripts. If you can show continuous monitoring and rapid alerting, you satisfy the weekly requirement and close the window attackers rely on.
For iframe-based checkouts, the change surface includes the parent page DOM, all executing scripts, and security-impacting HTTP headers like Content Security Policy (CSP) and HSTS. Monitoring these headers is non-negotiable under 11.6.1; if an attacker can downgrade your CSP via a Man-in-the-Middle or a server misconfiguration, your 6.4.3 script integrity controls can be bypassed entirely.
11.6.1 and 6.4.3 are operationally linked. PCI guidance notes that an unauthorised change detected under 11.6.1 should trigger a review of your 6.4.3 controls. The two requirements are not parallel workstreams. One feeds the other.
Understanding that relationship in theory and implementing it correctly in a live checkout environment are two different problems. The gap between them looks almost identical across organisations.
Where Teams Get This Wrong
The most consistent failure pattern in SAQ A-EP assessments is not ignorance of the requirements. It is a scoping assumption that was never challenged.
Teams assume analytics and marketing scripts are out of scope because they are not payment-related. PCI guidance says otherwise. Advertising, tracking, and tag management scripts can load additional external code and can be abused for skimming. If it executes in the browser on a payment page, it is in scope.
Teams treat their script inventory as a one-time deliverable. 6.4.3 requires ongoing management. 11.6.1 requires ongoing detection. A spreadsheet completed before your last assessment is not a control. It is a record that your controls existed at a point in time.
SPA teams attempt to “route-gate” their compliance. They assume only the /checkout route matters. However, PCI v4.0.1 and subsequent 2025 FAQs clarify that if the execution environment is shared, the scope is shared. If a chat widget is loaded on the “Support” page and that script persists in the background while the user enters card data in a separate component, that widget is in scope for 6.4.3.
Teams also misread 11.6.1 as a scan requirement rather than a detection mechanism. Running a scanner occasionally is not the same as having a system that catches unauthorized changes and alerts personnel. The distinction matters to your QSA.
Every one of these failures has the same root cause. The controls that 6.4.3 and 11.6.1 require are not one-time implementation tasks. They are ongoing operational commitments. And at the pace most checkout environments change, manual processes cannot keep up.
How PaymentGuard Handles the Heavy Lift
PCI guidance recognises that entities may consider specialised script management tools as an approach to meeting the objectives of script authorisation, integrity, inventory, and change detection on payment pages. This is the category Feroot targets with PaymentGuard.
For SAQ A-EP teams, PaymentGuard automates the operational work that manual processes cannot sustain at scale: continuous script discovery from the browser perspective, approval and justification tracking, integrity verification, real-time change detection, and QSA-ready reporting. In environments where stealthy e-skimming attacks can preserve a functioning checkout while exfiltrating data, reducing dwell time is operationally meaningful beyond compliance. The evidence problem, maintaining an audit trail that demonstrates ongoing compliance rather than point-in-time compliance, is where manual approaches typically break down and where automated tooling earns its place.
The tool doesn’t change what the requirements demand. It changes whether meeting them is actually sustainable.
The Iframe Was Never the Boundary
Hosted payment solutions reduce your exposure to card data. They do not reduce your responsibility for the page that surrounds the payment component. SAQ A-EP exists because the browser assembles your checkout experience from everything on the page, not just what lives inside the iframe.
Requirements 6.4.3 and 11.6.1 translate that risk into concrete controls: govern every script on the payment page and maintain continuous visibility into what changes. Align your scope with your acquirer and QSA. Then build controls that can generate evidence, not just at assessment time, but every week the page is live and every session a customer completes a purchase on it.
If your current posture relies on periodic manual reviews or the assumption that the payment iframe puts you out of scope, the gap between where you are and what 6.4.3 and 11.6.1 actually require is larger than it looks on paper.
