SAQ-A for Hosted Checkout Pages: What You Need to Know
If your business accepts online payments using a hosted checkout page — like Stripe Checkout, Adyen Drop-in, or your payment gateway's hosted payment page — you've probably been told you qualify for SAQ-A. That's likely true. But PCI DSS v4.0.1 introduced changes that catch many merchants off guard.
This post breaks down what SAQ-A covers, who qualifies, what changed in v4.0.1, and what you actually need to do.
What Is SAQ-A?
SAQ-A is the shortest Self-Assessment Questionnaire under PCI DSS — around 26 questions. It's designed for merchants who have fully outsourced all payment processing to PCI DSS-validated third-party service providers (TPSPs). Your systems never store, process, or transmit cardholder data. The payment provider handles everything.
For e-commerce merchants, this typically means one of two setups:
Redirect: The customer clicks "Pay" on your site and is sent to the payment provider's domain — a Stripe-hosted checkout page, for example. The entire payment form lives on the provider's infrastructure. Your site never touches card data.
iFrame (embedded payment form): Your checkout page embeds the payment provider's form inside an inline frame. The card input fields are rendered by the provider's servers, not yours. Your page surrounds the iFrame but never handles the card data itself.
In both cases, the principle is the same: cardholder data is entered into and processed by systems controlled entirely by your TPSP, not by you.
Who Qualifies for SAQ-A?
To use SAQ-A, you must meet all of these conditions:
- You are an e-commerce or mail-order/telephone-order (MO/TO) merchant.
- All processing of account data is entirely outsourced to PCI DSS-validated TPSPs.
- You do not electronically store, process, or transmit any account data on your systems or premises.
- You have confirmed that all TPSPs handling your account data are PCI DSS compliant.
- Any cardholder data you retain is on paper only (e.g., printed receipts or MO/TO order forms), and these documents are not received electronically.
If any system component in your environment touches cardholder data — even temporarily, even encrypted in transit through your server — SAQ-A is not the right questionnaire. You're likely looking at SAQ A-EP or SAQ D.
The v4.0.1 Change That Matters: Script Security on Your Payment Page
Under previous versions of the standard, SAQ-A for e-commerce merchants was almost entirely about confirming your outsourcing arrangements and TPSP compliance. Your own website was largely out of scope.
PCI DSS v4.0.1 changed that. Two requirements — previously only applicable to merchants with more complex setups — now apply to SAQ-A e-commerce merchants:
Requirement 6.4.3 — Payment page script management. All scripts that load and execute on your payment page (the page containing the iFrame or the redirect) must be actively managed:
- Each script must be authorized — you know it's there and you've approved it.
- Each script's integrity must be assured — you have a mechanism to detect if it's been tampered with (e.g., Subresource Integrity, Content Security Policy).
- An inventory of all scripts must be maintained, with written justification for why each one is necessary.
Requirement 11.6.1 — Payment page tamper detection. A change- and tamper-detection mechanism must be in place for your payment page. This mechanism must:
- Alert personnel to unauthorized modifications to the HTTP headers and page content as received by the consumer's browser.
- Evaluate the received HTTP headers and payment page content.
- Run at least once every seven days, or at a frequency defined by your targeted risk analysis per Requirement 12.3.1.
Why This Matters for Hosted Checkout Merchants
The reasoning is straightforward: even if you use a redirect or iFrame, your website still serves the page that triggers the payment flow. If an attacker compromises a script on your page, they can potentially:
- Overlay a fake payment form on top of your legitimate iFrame.
- Redirect the customer to a lookalike phishing page instead of your TPSP.
- Inject a skimmer that captures card data before the customer reaches the hosted form.
This is not theoretical. E-commerce skimming attacks (often called "Magecart" attacks) have exploited exactly this vector — compromising third-party scripts on the merchant's page to intercept payment data before it ever reaches the hosted checkout.
Requirements 6.4.3 and 11.6.1 exist to close that gap.
What You Actually Need to Do
If you're an e-commerce merchant using SAQ-A with a hosted checkout, here's what's required in practice:
1. Inventory your payment page scripts. Identify every JavaScript file, tag manager, analytics pixel, and third-party script that loads on the page where payment is initiated. Document each one and record why it's needed.
2. Authorize and control those scripts. Remove anything unnecessary. For everything that remains, ensure you have a documented approval. Consider implementing a Content Security Policy (CSP) to restrict which domains can serve scripts on your payment page.
3. Ensure script integrity. Use Subresource Integrity (SRI) hashes where possible. If a script changes without your knowledge, it should fail to load or trigger an alert.
4. Deploy tamper detection. Implement a mechanism that monitors your payment page for unauthorized changes. Options include CSP violation reporting, synthetic monitoring services that periodically fetch and compare your payment page, or commercial solutions designed specifically for 11.6.1 compliance.
5. Confirm your TPSP's coverage. SAQ-A allows merchants to confirm that their TPSP is responsible for requirements 6.4.3 and 11.6.1 on the merchant's behalf, but only if the TPSP actually provides that service. Check your provider's documentation carefully. If your TPSP's responsibility stops at the iFrame boundary, then 6.4.3 and 11.6.1 on your parent page are your problem.
Common Mistakes
"My payment provider handles everything." They handle the payment form. They don't control your website. If you load Google Analytics, a chat widget, a tag manager, and three marketing pixels on the same page as your payment iFrame, those are your scripts to manage.
"We don't have a payment page — we redirect." The page that initiates the redirect is your payment page. If JavaScript on that page can modify the redirect URL, it's in scope for 6.4.3 and 11.6.1.
"We'll just say our TPSP covers it." Your QSA or acquirer will want evidence. If your TPSP doesn't explicitly confirm they cover 6.4.3 and 11.6.1 for your specific integration, you're on the hook.
"SRI and CSP are developer problems, not compliance problems." They're both. If your development team doesn't implement these controls, you can't attest to 6.4.3. This is one area where compliance and engineering need to align.
SAQ-A vs. SAQ A-EP: Where's the Line?
The most common source of confusion is the boundary between SAQ-A and SAQ A-EP. The dividing line is whether your web environment can affect the security of the payment transaction:
- SAQ-A: Your site redirects to or embeds a third-party payment form. Your server never receives, processes, or transmits cardholder data. Your site's role is limited to initiating the payment flow.
- SAQ A-EP: Your e-commerce site uses a direct API integration where your JavaScript or server-side code directly participates in the payment flow — for example, calling a tokenization API client-side and posting the token to your server. Your web environment could be exploited to intercept card data even though you don't intend to handle it.
If you're using a direct post or client-side JavaScript SDK that creates and submits payment data (even as tokens) through your domain, SAQ A-EP is almost certainly more appropriate — and it comes with roughly 191 requirements instead of 26.
Find Your SAQ
Not sure whether SAQ-A is right for your environment? Our What SAQ Am I? quiz walks you through the key questions and tells you exactly which questionnaire fits your payment setup — in under two minutes.
Already know SAQ-A is your path? PCI DSS Dashboard walks you through every requirement in plain English, tracks your evidence, and generates a signed, downloadable attestation your acquirer actually needs.
