How iframes Simplify PCI DSS Compliance for E-commerce Businesses

An iframe lets a payment provider's card form sit inside your checkout page while the card data goes straight from the customer's browser to the provider. Done properly, it keeps your own systems out of the card data path, and that is what lets many e-commerce merchants use the shortest questionnaire, SAQ A. This article covers how the integration choices compare, what SAQ A then asks of an iframe merchant, and what an iframe does not protect against.

The integration decides the SAQ

The SAQ Instructions and Guidelines (v4.0.1 r1) set out which e-commerce integrations lead to which questionnaire:

Integration	SAQ, if eligible	PCI DSS requirements in it
The provider hosts and manages the whole page; you have no access to it	SAQ A	14
Your page redirects the customer to the provider's page	SAQ A	27
Your page embeds the provider's page or form, for example in an iframe	SAQ A	27
Your page builds the form and the browser posts card data straight to the provider (Direct Post)	SAQ A-EP	139
Your page loads a script that builds the payment page or controls how the data is sent	SAQ A-EP	139
Anything else	SAQ D	All

The line the instructions draw is whether any element of the payment page delivered to the customer's browser originates from your website. With Direct Post your server still does not receive the card data, but your page creates the form, which is why it is an A-EP integration.

Which route you validate by at all, SAQ or Report on Compliance, is set by the payment brands and your acquirer, whatever the integration. Find my SAQ works through the full eligibility criteria.

What SAQ A asks of an iframe merchant

Two things apply to a merchant whose page embeds the provider's form:

• External vulnerability scans. SAQ A for v4.x includes 11.3.2 and 11.3.2.1: quarterly scans by an Approved Scanning Vendor, and scans after significant change. The Council's FAQ 1604 confirms these apply to merchants whose pages redirect to a provider or embed its iframe, because a compromised merchant page can compromise the payment process.
• The script criterion. SAQ A's eligibility criteria require the merchant to have confirmed that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council's FAQ 1588 (February 2025) says this criterion applies only to merchants whose page includes the provider's embedded payment page or form, such as one or more iframes. It does not apply to a redirect or to fully outsourced payment.

FAQ 1588 gives two ways to confirm the script criterion:

1. protect your page from scripts targeting account data with techniques such as those in 6.4.3 and 11.6.1, deployed by you or a third party; or
2. get confirmation from your PCI DSS compliant provider that its solution, implemented according to its instructions, includes techniques that protect your payment page from script attacks.

The SAQ instructions' change log records 6.4.3 and 11.6.1 being removed from SAQ A and this criterion being added. Both remain requirements for SAQ A-EP, SAQ D and a full assessment. Scripts on your own page that only provide non-payment functions, such as analytics, do not make their provider a third-party service provider for SAQ A purposes, according to the same FAQ, but they are exactly the kind of script the criterion is about.

What an iframe protects, and what it does not

The browser's same-origin policy stops a script on your page reading the fields inside a frame served from the provider's domain. That separation is why an iframe integration can qualify for SAQ A.

It does not protect the page around the frame. A malicious or compromised script on your page can remove the frame and draw a look-alike form, cover it, or send the customer somewhere else afterwards. None of that reads the provider's frame, and all of it can capture card data. That is e-skimming, and it is why the script criterion exists. The guidance to 6.4.3 suggests restricting where the payment frame may be loaded from with the parent page's Content Security Policy, for example:

Content-Security-Policy:
  default-src 'self';
  frame-src https://pay.provider.example;
  script-src 'self';

The provider's own scripts inside its frame are its responsibility, not yours; the applicability notes to 6.4.3 say so for entities assessed against that requirement.

Hosted fields and provider scripts

Many providers offer "hosted fields": each card field is its own small iframe from the provider, placed into your form by a script you load. FAQ 1588 speaks of "one or more inline frame(s)", so several frames can still be an embedded form. The SAQ instructions, however, put a merchant website that loads a script providing functionality that supports creation of the payment page on the A-EP side. Which side a given provider's integration falls on depends on how it is built; ask the provider to state which SAQ its integration supports, and confirm with your acquirer before relying on SAQ A.

A checklist for an iframe integration

• Your systems do not store, process or transmit card data, electronically or otherwise, beyond paper the SAQ allows.
• Every element of the payment form comes only and directly from a PCI DSS compliant provider.
• You have the provider's current Attestation of Compliance for the service, and a written agreement in which it acknowledges its responsibility (12.8.2).
• You have confirmed the script criterion by one of FAQ 1588's two routes, and kept the evidence.
• Quarterly ASV scans of your web pages pass.
• Your acquirer agrees SAQ A is right for you.