Hosted payment pages, iframes and PCI scope
Embedding your provider's payment iframe reduces your scope substantially. It does not take the page around it out of scope, and that distinction is where most confusion lives.
TL;DR
Hosted payment pages and scope
WHAT IT IS
A payment form hosted by your provider, either as a full redirect or embedded in your page as an iframe or hosted fields.
WHAT IT REMOVES
Card data never touches your systems, which takes a great deal out of your cardholder data environment and can shorten your questionnaire.
WHAT IT DOES NOT REMOVE
The page hosting the iframe is yours, and a script on it can overlay the form or read keystrokes before the iframe does.
Short on time? Same-origin policy protects the inside of the iframe. It does nothing for the page around it.
What is a hosted payment page?
A hosted payment page is a payment form served and controlled by your payment provider rather than by you, either as a full redirect to their domain or embedded into your page as an iframe or as hosted input fields. The purpose is scope reduction. If the card number is typed into a form served from your provider's domain, the data never reaches your systems, so your servers, databases and logs fall outside the cardholder data environment. This is a genuine and substantial reduction, and it is why most merchants use one. What it does not do is remove your own page from the picture, and that is where the PCI conversation usually gets interesting.
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
Three models, three scope outcomes
Model
How it works
Typical scope effect
Full redirect
Customer leaves your site for the provider's domain
Largest reduction. Often SAQ A eligible
Iframe
Provider's form embedded in your page
Large reduction, parent page still yours. SAQ A if you meet FAQ 1588
Hosted fields
Individual provider-controlled inputs inside your own form
Similar to iframe, with more of your code adjacent to the fields
All three keep card data off your servers. The difference is how much of your own code sits next to the point of entry, and that is exactly what 6.4.3 and 11.6.1 are concerned with.
What the iframe boundary actually protects
Browser same-origin policy prevents a script on your page from reading inside a cross-origin iframe. That is a real, browser-enforced protection and it is the reason this model reduces scope.
It does not prevent a script on your page from doing any of the following, all of which are documented techniques:
Drawing a convincing fake payment form over the top of the iframe, so the customer types into the attacker's form instead
Capturing keystrokes at the document level before the iframe receives them
Replacing the iframe's source with a lookalike the attacker controls
Reading order details, email and address from the surrounding page, which is still useful data
Redirecting the customer entirely at the moment of payment
The page around your payment iframe is the page to monitor.
So is the parent page in scope?
Yes, for the client-side requirements. A page that embeds a payment iframe is a page where a cardholder enters card data, and it is where a malicious script would sit. Monitoring has to run on the parent page, above the iframe, to observe any of the techniques above. If you are validating with SAQ A, PCI SSC FAQ 1588 also accepts a second route: written confirmation from your PCI DSS compliant payment provider that its solution, implemented to its instructions, protects your page from script attacks.
This is also the pricing consequence: page views on the parent page are what you meter, because that is where the tag runs.
Which questionnaire applies
A full redirect often supports SAQ A. An embedded provider iframe can also be SAQ A, if you meet the script eligibility criterion that PCI SSC FAQ 1588 explains. Payment fields or scripts served from your own site frequently mean SAQ A-EP, because your site can affect the security of the payment transaction. A-EP carries 6.4.3 and 11.6.1 without exemption. Confirm your classification with your acquirer rather than inferring it, because it changes the size of your obligation considerably. See SAQ A and the script requirements.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read. Primary sources: PCI SSC FAQ 1588 and PCI SSC FAQ on 3DS scripts.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
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, 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.
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.
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.
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.
Often SAQ A. PCI SSC FAQ 1588, published in February 2025, treats an embedded provider iframe as eligible for SAQ A as long as you can confirm your site is not susceptible to script attacks. Some assessors still land on A-EP, so confirm with your acquirer.
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, 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.
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.
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.
For SAQ A eligibility, it can. PCI SSC FAQ 1588 accepts written confirmation from your PCI DSS compliant payment provider that its solution, implemented according to its instructions, protects your payment page from script attacks. Get it in writing for the product and integration you use; a statement that the provider is PCI compliant is not that confirmation.
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.
Related articles
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
PCI DSS
PCI DSS 4.0.1 requirements: what changed and when
The changes that matter, the dates that already passed, and the two requirements most teams missed.
PCI DSS
How to comply with PCI DSS 6.4.3 and 11.6.1
A step-by-step method, from defining payment-page scope to handing an assessor the evidence.
PCI DSS
SAQ A and the script requirements: who is exempt
The January 2025 carve-out is narrower than most people think. Here is what it actually says.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.