The January 2025 SAQ A change: embedded provider fields and the script-attack criterion

November 6, 2026 · Compliance Assessment Tool

Short answer. In January 2025, SAQ A was revised so some e-commerce merchants using card fields embedded from a compliant payment provider can use SAQ A instead of SAQ A-EP. The key test is not whether checkout happens on your website, but who supplies the card form and whether your site is protected against script attacks, or the provider confirms that protection in writing.

What changed in January 2025

The practical change is simple: an e-commerce merchant may be eligible for SAQ A when the card entry fields are embedded from the payment provider, not only when the customer is sent to a fully hosted payment page.

Before this revision, many merchants with embedded checkout were pushed toward SAQ A-EP because the payment step appeared on the merchant's own website. The January 2025 SAQ A revision shifted the focus to who actually supplies the card form and how the page is protected.

For merchants, that can mean a shorter and more accurate validation path. For ISOs, it reduces one of the most common sources of confusion in e-commerce PCI conversations: merchants describing an embedded provider checkout as "hosted" without realizing that the SAQ result depends on the details.

If you want the background on the SAQ categories, Which SAQ do I need? is a useful starting point, and SAQ A vs SAQ A-EP goes deeper on the distinction.

Old assumption: if checkout stayed on the merchant's website, it was often treated as A-EP.
New focus: if the payment provider supplies the card fields, SAQ A may apply.
Important condition: the merchant still needs protection against script attacks, or written confirmation from the provider about that protection.

What counts as embedded provider fields

Embedded provider fields are card input fields delivered by the payment provider into the merchant's checkout page. The customer sees the payment step on the merchant's site, but the card form itself is not built by the merchant's code.

That is different from a checkout where the merchant's own website creates the card form and sends card data directly to the processor. In that model, the merchant controls the form itself, which is why SAQ A-EP may still be the better fit.

The easiest plain-English test is this: if your provider is supplying the actual card number, expiry and similar entry fields, the January 2025 revision may open the door to SAQ A. If your developers built those fields themselves, the revision does not change much.

PCI SSC materials are still the primary source for exact eligibility language. The PCI SSC Document Library and PCI SSC FAQ 1588 are the right references when an ISO or merchant needs to confirm the script-related criteria.

Embedded provider fields: the provider supplies the card form inside the checkout page.
Hosted payment page: the customer is redirected to the provider's page.
Merchant-built form: the merchant's site creates the card form, which points more toward A-EP than A.

What the script-attack criterion means in plain English

The new question many merchants are asking is not "Can I stay on my own checkout page?" but "What does protected against script attacks mean?" In plain English, it means the payment page cannot be left exposed to unauthorized scripts that could interfere with or skim the checkout experience.

This matters because even if the payment provider supplies the embedded card fields, the merchant's website still presents the page around those fields. If that surrounding page can be altered by a malicious script, cardholder data security can still be put at risk.

The revised SAQ A approach recognizes this reality. A merchant may be eligible for SAQ A when the provider supplies the card fields and either the merchant protects the site against script attacks or the provider confirms that this protection is in place in writing.

For ISOs, the operational takeaway is important: "embedded" alone is not enough. Your merchants need a clean way to describe how checkout works, and someone needs to confirm whether the script-attack criterion is met before deciding that SAQ A is the right path.

The card fields can come from the provider and still appear on the merchant's website.
The surrounding page still matters.
Embedded checkout is not automatically SAQ A just because card data goes to the provider.
Written confirmation from the provider may be part of the merchant's basis for using SAQ A.

Common mistakes merchants and ISOs should avoid

The most common mistake is treating every embedded checkout the same. Two merchants may both say, "Our processor hosts the payment fields," but one may truly be using provider-supplied secure fields while the other is using a merchant-built form that posts directly to the provider.

Another mistake is assuming the domain decides the SAQ by itself. Under the January 2025 revision, being on the merchant's own website does not automatically mean A-EP. What matters more is who supplies the card form and whether the script criterion is satisfied.

A third mistake is using broad labels like "hosted checkout" or "integrated checkout" in merchant onboarding. Those phrases are too vague to determine the correct SAQ. ISOs get better results when they ask merchants to describe the payment experience in ordinary words, including where the card fields come from and whether the provider has documented the script protections.

Finally, do not treat SAQ selection as a one-time website classification. A merchant can have more than one payment method and may need a separate SAQ for each payment method. An online checkout using embedded provider fields and a browser-based virtual terminal used by staff are not the same payment method and should not be collapsed into one assessment.

Do not assume all embedded checkouts qualify for SAQ A.
Do not decide based only on whether the page is on the merchant's domain.
Do not rely on vague merchant labels like "hosted" or "integrated."
Do not combine different payment methods into one SAQ decision.

How to operationalize the change without confusing merchants

For e-commerce merchants, the best next step is to document the checkout flow in plain language. State whether the provider supplies the card fields, whether customers are redirected away from the site, and whether the provider has confirmed the script-attack protection in writing. That gives your acquirer or ISO a factual basis for the SAQ discussion.

For ISOs, the January 2025 change is really a workflow problem. If your team asks merchants technical questions in PCI jargon, many merchants will guess. A better process starts with plain-English descriptions of how payments are accepted and uses follow-up questions only where needed.

That is exactly the kind of workflow we built CAT for. Merchants describe how they take payments in plain words, AI determines which of the 9 SAQ types applies, asks a plain-English follow-up when needed, and then generates the official SAQ and AoC PDFs for the merchant to review and sign digitally.

If you are embedding PCI into your own merchant flow, CAT can be delivered in four ways to fit your channel: REST API, MCP integration for AI agents and bank chatbots, an embeddable iframe, or a white-label portal handoff. You can see the overview at PCI compliance API overview or review the Integration docs.

Ask merchants how the card form is supplied, not just whether checkout is "hosted."
Confirm the script-attack criterion before assuming SAQ A.
Keep separate payment methods separate for SAQ purposes.
Use a process that produces the official SAQ and AoC documents after merchant review and signature.

Why this change matters for merchant experience

When merchants are put into the wrong SAQ, the result is usually predictable. If the questionnaire is longer than it needs to be, they stall or abandon it. If it is too short for the real payment setup, the risk is not being addressed properly.

The January 2025 SAQ A revision gives e-commerce merchants using embedded provider fields a more accurate route in many cases. But accuracy still depends on getting the checkout details right and not skipping the script-attack question.

For ISOs, this is one of the strongest arguments for making PCI validation part of your existing onboarding and support flow instead of sending merchants into a generic questionnaire. The closer your process is to the merchant's actual payment setup, the less guesswork there is.

If you want to test an API-first way to do that, we offer a free sandbox at Free sandbox. Partners can create merchants, add payment methods, determine the SAQ type, run the questions, collect the signature, and download the completed SAQ and AoC PDFs from their own systems.

A more accurate SAQ path usually means less merchant confusion.
The script-attack criterion is now central to many embedded checkout decisions.
Operational clarity matters as much as technical accuracy.
A partner-led, white-label process helps keep the merchant relationship with the ISO or bank.

Common questions

Does embedded checkout now always qualify for SAQ A?

No. The January 2025 change does not mean every embedded checkout is SAQ A. The key points are whether the payment provider supplies the card fields and whether the site is protected against script attacks, or the provider confirms that protection in writing.

If the customer stays on our website, does that mean we need SAQ A-EP?

Not necessarily. After the January 2025 SAQ A revision, staying on the merchant's website does not automatically push an e-commerce merchant into A-EP. What matters is who supplies the card form and whether the script-related eligibility criterion is met.

What should an ISO ask a merchant to determine whether SAQ A may apply?

Ask the merchant to describe the checkout in plain English: whether customers are redirected, whether the provider supplies the card entry fields, and whether the provider has documented script-attack protection. Those answers are more useful than labels like hosted, integrated, or embedded.

Can one merchant have SAQ A for one payment method and a different SAQ for another?

Yes. PCI validation should be considered per payment method, not just per merchant. A merchant with an embedded e-commerce checkout and a separate browser-based virtual terminal may need different SAQs for those different ways of taking card payments.

An API for PCI compliance

Give every merchant the right SAQ, in plain English, under your brand — by REST API, MCP, iframe or redirect. $25 per completed assessment.

Get a free sandbox → How the API works

More from the blog

General information, not legal advice. Your acquirer decides which SAQ a merchant must file. PCI DSS v4.0.1.