Picking the Right SAQ Type in Plain English

October 30, 2026 · Compliance Assessment Tool

Short answer. The right SAQ type depends on exactly how your business takes card payments, not on your industry or size. If you pick the wrong one, you can end up with a longer questionnaire than you need, a poor merchant experience, or a compliance record that does not match how you actually take payments.

Why SAQ type matters more than most small businesses expect

Most small businesses do not struggle with PCI because they refuse to do it. They struggle because the first question is confusing: which SAQ am I supposed to complete?

That choice matters because there are 9 SAQ types, and each one is meant for a different payment setup. If the SAQ is too broad, you may face questions that do not fit your business. If it is too narrow, your paperwork may not reflect the way you really accept cards.

A lot of frustration around PCI starts here. Business owners get sent a questionnaire full of technical language, try to guess, and then either abandon it or complete the wrong form just to get it off their list.

Your SAQ type is based on how card payments are handled.
A storefront terminal, an online checkout, and a virtual terminal can lead to different SAQs.
One business may need more than one SAQ if it accepts cards in more than one way.

The plain-English way to think about SAQ types

You do not need to memorize the names of all 9 SAQ types to understand the basics. Start with a simpler question: where is the card data entered, and what system provides that card form or device?

If your customers pay through a hosted payment page or secure embedded fields supplied entirely by your payment provider, that often points toward SAQ A. If your own website builds the payment form while sending card data straight to the provider, that can point toward SAQ A-EP.

If you use only standalone terminals, the SAQ may be different from a business that types card numbers into a browser-based virtual terminal. If you have a more complex setup, or several ways of taking payments, you may land in a broader SAQ type.

The January 2025 revision to SAQ A under PCI DSS v4.0.1 made one point especially important for ecommerce merchants: what matters is who supplies the card form, not simply which website the customer is on. The PCI SSC also explains the script-related eligibility point in FAQ 1588.

If you want a deeper walkthrough of the categories, Which SAQ do I need? and SAQ A vs SAQ A-EP are good places to start.

Hosted payment page or provider-supplied embedded fields: often SAQ A.
Your own site builds the card form: often SAQ A-EP.
Standalone terminal, virtual terminal, and other setups each map differently.
The acquirer decides which SAQ a merchant must file.

The cost of picking the wrong SAQ

The first cost is time. If you pick an SAQ that does not fit your payment setup, you may get a questionnaire that is much longer and more technical than necessary. Small businesses often stall at that point because the questions do not sound like their day-to-day reality.

The second cost is rework. A merchant may complete a form, submit it, and later learn that the wrong SAQ was used. That means going back, answering a different set of questions, and spending more time with support teams, processors, or bank contacts.

The third cost is confusion inside your business. If one person handles the website, another runs the front desk, and another person uses the terminal, it is easy to give inconsistent answers when the SAQ type was wrong from the start.

There is also a relationship cost. Merchants often first notice PCI through a PCI non-compliance fee on their statement, but the real frustration is usually that no one explained the questionnaire in plain English. A bad fit at the SAQ stage makes that frustration worse.

Finally, there is the risk of an incomplete picture. If your business accepts cards in more than one way but only one payment method gets reviewed, your compliance paperwork may leave out an important part of how you actually operate.

Wrong SAQ types create longer or less relevant questionnaires.
Merchants may have to redo the assessment.
Internal answers can become inconsistent.
Missing a payment method can leave part of the business unaddressed.

Common examples that trip up small businesses

An online business may assume it automatically needs the ecommerce SAQ with more questions, even when the card fields are actually supplied by the payment provider. After the January 2025 SAQ A revision, some merchants using provider-supplied embedded fields may fit SAQ A rather than A-EP, depending on the setup.

A service business may think, "We only key cards into a website," and not realize that a browser-based virtual terminal is its own category. That is different from using a standalone countertop terminal.

A shop with both an in-person terminal and an online payment link may think it should choose a single SAQ for the whole business. In practice, the payment methods may need to be looked at separately because one merchant can take cards in more than one way.

Businesses also get tripped up when they describe technology instead of the payment experience. Saying, "We use an ecommerce platform," is not enough. What matters is whether the card form comes from the provider, whether your site builds it, whether staff key card numbers into a browser, or whether a terminal handles the transaction.

Do not assume all ecommerce setups are the same.
A virtual terminal is not the same as a physical terminal.
A business with multiple payment methods may need separate SAQs.
Describe how payment happens, not just the software name.

How we think small businesses should approach SAQ selection

Start by listing every way you accept card payments today. Countertop terminal, online checkout, emailed payment link, phone order entered into a browser, mobile device, or anything else. Be specific.

Then describe each payment method in plain language. A useful description sounds like, "Customers enter card details into fields provided by our payment company on our checkout page," or, "Our staff type the card number into a virtual terminal in a browser." That is much easier to classify than a vague answer like, "We take payments online."

This is also why we built CAT the way we did. Merchants describe how they take payments in plain words, AI determines which of the 9 SAQ types applies, and if needed asks a plain-English follow-up question. From there, every question is written for that business and payment method in plain English, and each answer shapes the next.

For businesses that accept cards more than one way, CAT supports one SAQ per payment method. When the merchant is done, they review and sign digitally and get the official PCI SSC SAQ and AoC PDFs filled in.

If you want to understand the broader process, the PCI SSC keeps the official source documents in its Document Library. If you are a platform, ISO, PayFac, or bank looking to offer this experience to merchants inside your own systems, our PCI compliance API overview explains the delivery options.

List each payment method separately.
Use plain-English descriptions of how card data is entered and handled.
Review ecommerce setups carefully after the January 2025 SAQ A revision.
Treat SAQ choice as a payment-method question, not a business-type question.

A simpler path for merchants and the partners who support them

Small businesses should not have to decode PCI terminology before they can answer basic questions about their own checkout or terminal. The simpler the intake, the more likely the assessment gets completed accurately.

That matters to the partners supporting merchants too. ISOs, PayFacs, and sponsor banks need a clear view of who has completed, who is in progress, and who has not started. CAT provides that portfolio visibility, along with annual renewal tracking, signed webhooks for status changes, and four ways to integrate: REST API, MCP server, embeddable iframe, or a white-label portal experience.

For merchants, the benefit is straightforward: answer questions written for your actual payment methods, not a generic script. For partners, the benefit is being able to deliver PCI compliance from their own systems without sending merchants through a disconnected process.

If you want to see how it works, start with the PCI compliance API overview or request a free sandbox.

Common questions

How do I know which SAQ type I need?

Start with how you take card payments, not your industry. The main questions are where card data is entered, who supplies the payment form or device, and whether you accept cards in more than one way. Your acquirer decides which SAQ you must file.

Can one small business have more than one SAQ?

Yes. If you accept cards through different payment methods, such as a countertop terminal and an online checkout, each payment method may need its own SAQ. The key is to evaluate each payment flow separately.

What is the most common SAQ mistake for ecommerce merchants?

A common mistake is assuming all online checkouts fall into the same SAQ. Under the January 2025 SAQ A revision, some merchants using provider-supplied embedded fields may fit SAQ A rather than A-EP, depending on how the card form is delivered and protected.

What happens if I complete the wrong SAQ?

Usually the immediate result is wasted time and rework. You may need to redo the assessment, answer a different set of questions, or clarify your payment setup with your processor or bank. It can also create confusion if the form does not match how your business actually takes payments.

Does CAT decide compliance for my business?

CAT helps merchants describe their payment methods in plain English, determines the likely SAQ type for each payment method, and produces the official SAQ and AoC PDFs after digital signature. The acquirer decides which SAQ a merchant must file.

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.