A merchant moved card entry into its provider's hosted iframe in 2023 and files the shortest card-compliance questionnaire. The checkout page around that iframe loads eleven third-party scripts: a tag manager, two analytics tools, session replay, a chat widget, a fraud SDK and four advertising pixels. The team says the iframe puts all of it out of scope. Review that.

What is actually required

The iframe does real work: card fields live in the provider's document, so the merchant's JavaScript cannot read them and the card number never reaches merchant systems. What the iframe does not do is control what else the browser executes on the page that contains it. A script on the parent page can draw a convincing overlay on top of the frame, replace the frame's source, or watch for the moment a page re-renders the form inline during a fallback. The card data is isolated; the page is not.

PCI DSS v4.0's future-dated requirements became effective on 31 March 2025, and two of them are about this page. Requirement 6.4.3 asks for every script on a payment page to be authorised, to have its integrity assured, and to appear in an inventory with a written justification. Requirement 11.6.1 asks for a mechanism that detects and alerts on unauthorised change to the payment page's HTTP headers and content. In 2025 the Council also revised the shortest questionnaire: those two requirements are no longer line items on it, replaced by an eligibility criterion under which the merchant confirms its site is not susceptible to script attacks affecting the e-commerce systems, which is understood to apply where a payment form is embedded rather than where the customer is redirected away. The detail here moves, and the current questionnaire and the Council's own FAQs govern, so treat the design rule rather than the form number as the durable part: the page that frames the payment is part of the payment page's attack surface, and somebody has to attest to it.

What I would remove

Session replay, from this page, first and without negotiation. It exists to capture the DOM and input events, so it is an exfiltration channel by design, and field masking is a configuration that one release can silently break. Then the four advertising pixels and one of the two analytics tools: no advertising measurement needs to run on the step where money moves. That takes eleven scripts to three or four, each with a written reason.

The one change that matters

A content security policy with an explicit script-src allowlist and nonces, deployed in report mode first to find what breaks, then enforced. It converts "we reviewed the tags" into a control the browser enforces, and its violation reports double as the change-detection signal 11.6.1 asks for. Pair it with integrity attributes on any versioned asset and an alert on the payment page's response headers and script set.

What I would leave alone

The fraud SDK. It has a genuine justification on the checkout path, and the standard asks for justification and authorisation rather than removal. Put it in the inventory with its reason and pin its version.

When this is the wrong answer

If the business can tolerate a redirect, sending the customer to the provider's own hosted payment page removes the merchant page from the embedded-form criterion altogether and is far cheaper than running script governance on a page the marketing team edits weekly. The honest trade-off is a conversion-rate drop of a few percent on the hosted-page flow against a permanently smaller compliance surface. Measure the conversion difference rather than assuming it, because the engineering and assessment cost of the embedded path is annual and the conversion gap may be smaller than the team believes.