Iframe, Hosted Fields, or Redirect? Payment Integration Choices and SAQ A vs. SAQ A-EP
Few technical decisions carry as much hidden compliance weight as how your website collects a card number. Two checkouts can look pixel-identical to a shopper while one merchant answers a couple of dozen self-assessment questions each year and the other faces nearly two hundred, plus vulnerability scanning obligations. The dividing line is SAQ A vs. SAQ A-EP — and it is drawn almost entirely by your integration method: redirect, iframe, hosted fields, or direct API. This guide gives developers and merchants the map before the code gets written, because retrofitting is far more expensive.
Quick answer: SAQ A applies when card data capture is fully outsourced — the customer’s browser gets the payment form entirely from a PCI-compliant provider via a full redirect or a provider-hosted iframe. SAQ A-EP applies when your website affects how card data is captured or where it is sent — as with JavaScript hosted fields or direct-post integrations — and it carries several times the requirements, including external ASV scanning. Direct API capture disqualifies you from both, requiring SAQ D.
Why does the integration method decide the SAQ?
The logic is about influence. Even if card numbers never touch your server, a page you serve can be modified — by an attacker who compromises it — to redirect data anywhere. The more your code participates in building the payment form, the more your website’s security matters to the outcome, and the more of PCI DSS applies to you. That is the entire A / A-EP distinction in one sentence: SAQ A means your systems could be fully compromised and the attacker still wouldn’t control the payment form’s origin; SAQ A-EP means they would. (If SAQs are new territory, our merchant’s guide to PCI DSS self-assessment questionnaires covers the whole catalog.)
What are the four e-commerce integration patterns?
1. Full redirect / hosted payment page → SAQ A
The customer clicks “pay” and leaves your site entirely for a page served by your payment provider, returning after completion. Your site never renders any part of the payment form.
- Compliance: SAQ A — the lightest e-commerce footprint.
- Security: smallest attack surface on your side; the payment page inherits the provider’s hardening.
- Trade-offs: least design control; a visible domain change some merchants dislike; conversion impact is frequently overstated with modern providers but is real for poorly executed redirects.
2. Provider-hosted iframe → SAQ A
Your page embeds an iframe whose contents — the entire payment form — are served from the provider’s domain. The browser’s same-origin policy walls your page’s scripts off from the fields inside.
- Compliance: SAQ A, provided the entire form comes from the provider.
- Security: strong isolation, though not absolute — a compromised parent page can overlay a fake form on top of the real iframe. This is why PCI DSS 4.0’s script-management requirements reach the embedding page; see our guide to requirements 6.4.3 and 11.6.1.
- Trade-offs: styling is limited to what the provider’s iframe options expose; seamless look requires some CSS negotiation.
3. JavaScript “hosted fields” / direct post → SAQ A-EP
Your page renders the checkout, and provider JavaScript either builds individual input fields (often as micro-iframes per field) or tokenizes data from fields your page owns, sending card data browser-to-provider. Your server still never sees a PAN — but your page now materially constructs the capture experience.
- Compliance: SAQ A-EP — roughly 190 requirements versus SAQ A’s ~30, adding external ASV vulnerability scans, penetration-testing expectations, logging, and change control for the web environment.
- Security: maximum design flexibility, but your page’s JavaScript supply chain becomes the payment security perimeter — precisely the terrain of Magecart-style skimming attacks.
- Trade-offs: the compliance jump is the price of pixel-perfect checkout. Many merchants discover the A-EP obligation only when their acquirer asks for the ASV scan they’ve never run.
4. Direct API / server-side capture → SAQ D
Card data posts to your server, which forwards it to the processor. Even with zero storage, transmission through your systems puts you in SAQ D territory — the full standard, self-assessed. Legitimate reasons exist (complex orchestration, some MOTO flows, gateway-of-record architectures), but choose it knowingly, not accidentally.
Comparison at a glance
| Integration | SAQ | Approx. scale | ASV scans required | Design control | Primary residual risk |
|---|---|---|---|---|---|
| Full redirect | A | ~30 requirements | No | Low | Redirect tampering on your site |
| Hosted iframe | A | ~30 requirements | No | Medium | Parent-page overlay attacks |
| Hosted fields / direct post | A-EP | ~190 requirements | Yes | High | JavaScript supply-chain compromise |
| Direct API | D | Full standard | Yes | Total | Everything — you are the payment environment |
Requirement counts are approximate and vary by SAQ version; treat them as orders of magnitude, and confirm current questionnaires with your acquirer or QSA.
How should you choose?
- Default to SAQ A architectures. For most small and mid-size merchants, a well-implemented iframe or modern hosted page delivers 95% of the checkout experience at perhaps 15% of the compliance cost. Start here and demand a business case for leaving.
- Price the true cost of A-EP before choosing hosted fields. Quarterly ASV scans, remediation cycles, expanded policy and logging obligations, and assessment effort are recurring costs, not one-time setup. If brand-perfect checkout genuinely moves your conversion needle — some high-volume retailers can prove it does — budget the compliance program as part of the feature.
- Never let SAQ A become an excuse for a soft website. The questionnaire is short because capture is outsourced, not because your site stopped mattering: it still serves the button, the redirect target, and the iframe context. Basic hygiene — patching, admin MFA, script discipline per 6.4.3 — remains your job, and our developer’s guide to securing the checkout flow applies in full.
- Re-check the SAQ whenever checkout changes. A redesign that swaps the iframe for hosted fields silently reclassifies you. Make “does this change our SAQ?” a standard question in checkout-related design reviews.
- Get the classification in writing. Your acquirer or QSA is the authority on which SAQ applies to your exact implementation. Provider marketing pages are a starting point, not evidence.
Frequently asked questions
My provider says I’m “PCI compliant out of the box.” True?
No provider can make you compliant. They can make you eligible for a lighter validation. You still complete the applicable SAQ, meet its requirements, and manage the provider relationship itself under your obligations.
Does tokenization change my SAQ?
Tokenization governs what you store afterward; the SAQ split above is decided by how data is captured. The two work together — capture via SAQ A architecture, store only tokens — as explained in our comparison of network tokens and PCI tokens.
Is a redirect really more secure than hosted fields?
It concentrates risk differently: redirect/iframe models lean on the provider’s hardened environment and browser isolation; hosted fields lean on your page’s script hygiene. Given the industrial scale of client-side skimming, most security teams prefer the former for any merchant without a mature web-security program.
What is an ASV scan?
A quarterly external vulnerability scan performed by a PCI-approved scanning vendor against your internet-facing systems, required under SAQ A-EP and D. Failed findings must be remediated and rescanned to pass.
Can mobile apps use these categories?
Mobile SDKs from providers behave much like hosted fields conceptually, but SAQ applicability for native apps has its own nuances — ask your acquirer rather than assuming the web categories transfer.
Integration choice is compliance destiny. Decide it deliberately, document it, and revisit it whenever the checkout — or the SAQ definitions themselves — change.