Why a Business With a Terminal and an Online Store Files More Than One SAQ

November 10, 2026 · Compliance Assessment Tool

The short version: one way of taking cards, one SAQ

A small business can look simple on the surface: a countertop terminal in the shop and an online checkout on the website. But from a PCI point of view, those are two different payment methods, and they do not usually belong in the same questionnaire.

That is why a business with a terminal and an online store often files more than one SAQ. The terminal may fit one SAQ type, while the online checkout fits another. Keeping them separate is usually easier because each set of questions stays focused on the actual payment flow.

The important idea is this: PCI validation is about how card data is handled. If card payments happen in different ways, the compliance questions should match those different ways too.

• A standalone terminal and an online checkout are different payment methods
• Different payment methods can qualify for different SAQ types
• Separate SAQs are often shorter and clearer than one broad questionnaire

Why more than one SAQ is usually less work

At first, filing more than one SAQ sounds like extra admin. In practice, it often reduces effort because the alternative is often ending up in a broader SAQ that asks about systems and risks that do not apply to every part of your business.

For example, a terminal at the counter may have very little to do with your website. If you answer terminal questions separately, you stay focused on the devices, location and handling around that terminal. Then your online store can be assessed based on how the website takes payment, without dragging the store terminal into web questions it has nothing to do with.

This matters because picking the wrong SAQ type is one of the main reasons merchants get stuck. If the questionnaire is too broad, it feels confusing and heavy. If it is too narrow, your acquirer may reject it and ask you to start again.

Using separate SAQs also makes annual renewals easier. If one payment method changes, such as a new website checkout, you can review that payment method directly instead of treating the whole business as one undifferentiated card environment.

• Narrower questions are easier to understand
• You avoid answering irrelevant questions
• Changes to one payment method do not automatically complicate the other
• Separate renewals are easier to review and explain

A simple example: terminal in store, checkout online

Say you run a shop that uses a standalone internet-connected terminal at the counter and also sells through an online store. Those are not the same thing under PCI DSS v4.0.1.

The in-store terminal might fit a terminal-focused SAQ, depending on how the device works. The online store might fit SAQ A if the card form comes entirely from the payment provider, including secure fields embedded in your checkout, or a different SAQ if your own site builds the card form.

Since the January 2025 revision of SAQ A, some ecommerce merchants using provider-supplied embedded card fields can use SAQ A rather than A-EP, as long as the site is protected against script attacks or the provider confirms this in writing. What matters is who supplies the card form, not which website the customer is on.

If you want a deeper explanation of the online side, SAQ A vs SAQ A-EP is the key distinction to understand. For a broader overview, Which SAQ do I need? walks through the nine SAQ types in plain English.

• Countertop terminals and online checkouts are assessed differently
• The online SAQ depends on who provides the card form
• Embedded provider fields can still fit SAQ A under the January 2025 revision
• The acquirer decides which SAQ a merchant must file

What small businesses usually get wrong

The most common mistake is thinking there should be one PCI questionnaire for the whole business, no matter how cards are accepted. That sounds tidy, but it often creates more confusion than it solves.

Another common mistake is describing the online store too vaguely. Saying 'we take payments on our website' is not enough. The practical question is whether the payment provider supplies the card form, whether customers are redirected to a hosted page, or whether your own website builds the form and sends card data straight to the provider.

Terminal setups get oversimplified too. A business may say 'we just use a machine at the counter,' but details still matter: whether it is standalone, connected over the internet, part of a validated P2PE solution, or something more complex.

This is why plain-English intake matters. A merchant should be able to describe how they take payments in normal words, then answer follow-up questions only when needed. That is the simplest way to get to the right SAQ path without guessing.

• Do not assume one business means one SAQ
• Describe each payment method separately
• For ecommerce, focus on who provides the card form
• For terminals, focus on how the device is connected and used

How we handle this at CAT

We built CAT around the idea that a merchant may have more than one payment method, and that each one may need its own SAQ. The merchant describes how they take payments in plain words, and AI determines which of the nine SAQ types applies, asking a plain-English follow-up question when needed.

That means a business with a terminal and an online store does not get forced into one oversized questionnaire. Each payment method is handled separately, and every question is written for that business and payment method in plain English. Each answer shapes the next, so the merchant only sees questions that fit how they actually take cards.

At the end, the merchant reviews and signs digitally and gets the official PCI SSC SAQ and Attestation of Compliance PDFs filled in. For a bank, ISO or PayFac, that same structure also makes portfolio tracking cleaner because there is visibility into who has completed, who is in progress and who has not started.

CAT can be delivered four ways: REST API, MCP integration for AI agents and bank chatbots, an embeddable iframe, or a white-label portal. If you want to see the product shape behind that, start with our PCI compliance API overview.

• One SAQ per payment method
• Plain-English intake and follow-up questions
• Official SAQ and AoC PDFs filled in after digital signature
• Four ways to integrate for partners serving merchants

What to do next if your business takes cards more than one way

First, list each payment method separately. Do not start with 'what SAQ are we?' Start with 'how do we take cards?' If you have a terminal, an online store, a virtual terminal or any other distinct flow, write them down one by one.

Second, be precise about the online checkout. For script-related SAQ A questions, the PCI SSC has useful background in FAQ 1588. If you want the source documents, the PCI SSC Document Library is the official reference.

Third, remember that more than one SAQ is not a sign that something is wrong. It usually means your business accepts cards in more than one distinct way, and the cleanest path is to validate each way on its own terms.

If you are a bank, ISO or PayFac looking for a simpler way to deliver that experience to merchants, we offer a free sandbox the same day. You can start here: Free sandbox.

• List each payment method separately
• Be specific about how your website collects card details
• Use official PCI SSC guidance for edge cases
• Treat separate SAQs as a way to reduce confusion, not add it

Common questions

More from the blog

• Taking Card Payments by Phone Safely
• January 2025 SAQ A Change Explained
• White-label PCI for ISOs and banks
• Picking the Right SAQ Type for Your Business
• Embed SAQ Completion in Merchant Onboarding

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