Why ISOs Should Embed SAQ Completion in Merchant Onboarding

October 28, 2026 · Compliance Assessment Tool

Short answer. ISOs get better PCI completion rates when the SAQ is part of merchant onboarding, while payment setup details are still fresh and the merchant is already completing required tasks. Waiting until months later usually means more confusion, more chasing, and a higher chance the merchant abandons the process or answers the wrong questionnaire.

The short version

If PCI is treated as a separate follow-up project, it often becomes a cleanup exercise. By the time you ask for the SAQ, the owner may not remember how the checkout was configured, who supplied the card form, or which payment methods are actually live.

Embedding SAQ completion in onboarding fixes the timing problem. The merchant is already entering business details, choosing payment methods, and responding to required steps, so PCI fits naturally into the same flow instead of feeling like an unexpected admin task later.

For ISOs, the operational benefit is simple: fewer manual reminders, fewer misclassified questionnaires, and a clearer portfolio view from day one.

Why merchants struggle when PCI starts later

Most merchants do not think in SAQ names. They think in plain terms like "we key cards into a browser," "we use a countertop terminal," or "our website sends customers to a hosted payment page." Months after boarding, those facts are harder to recover accurately.

That is where mistakes start. A merchant may guess the wrong SAQ type, or give incomplete answers because the questionnaire feels disconnected from the way they actually take payments.

The result is usually one of two bad outcomes: the assessment is too long because the wrong SAQ was selected, or too short because important controls were never covered. Either way, your team ends up intervening.

This is also why non-compliance fees create so much frustration. From the merchant's point of view, they were approved to process, then later received a PCI task they did not understand. If you want background on that merchant experience, The PCI non-compliance fee is a useful reference.

Payment setup details are freshest during onboarding.
The person completing setup is usually available at that moment.
Required business tasks already have the merchant's attention.
Your operations team can correct issues before they turn into exceptions.

What an onboarding-first PCI flow should look like

A practical onboarding flow should start with how the merchant takes payments, not with SAQ jargon. Ask for each payment method separately, because one merchant can have more than one card acceptance flow and each payment method may need its own SAQ.

For example, a merchant might use a standalone terminal in person and also take payments through an online booking page. Those are different payment methods and should not be forced into a single generic questionnaire.

Once the merchant describes each payment method in plain English, the system should determine which of the 9 SAQ types likely applies and ask a follow-up question only when needed. This is usually the difference between a process merchants finish and one they abandon.

If you need a refresher on the SAQ families, Which SAQ do I need? is a good overview. For e-commerce specifically, SAQ A vs SAQ A-EP matters even more after the January 2025 SAQ A revision under PCI DSS v4.0.1, because eligibility turns on who supplies the card form and whether the site is protected against script attacks.

Collect payment methods during onboarding.
Treat each payment method separately.
Determine the likely SAQ type from the merchant's own description.
Use plain-English follow-up questions when the setup is ambiguous.
Present only the questions that fit that business and payment method.
Collect the merchant signature and provide the final SAQ and AoC documents.

How this helps ISO operations teams

Embedding SAQ completion in onboarding is not just better for merchants. It removes avoidable work for ISO operations and risk teams.

First, it reduces rework. If PCI begins while the merchant account is being set up, your team can resolve unclear payment descriptions before they become a support ticket months later.

Second, it creates a cleaner handoff between sales, onboarding, and portfolio management. Instead of wondering which merchants were invited manually or which spreadsheet is current, you can track who has completed, who is in progress, and who has not started in one place.

Third, it helps with annual renewals. Every completed assessment has an expiry, so if you capture the first SAQ at onboarding, the renewal cycle is easier to track later. That is much simpler than trying to reconstruct the portfolio after the fact.

For ISOs that are still designing their broader operating model, Starting an ISO covers some of the foundational considerations around building repeatable processes.

How we support an onboarding-first approach

We built CAT as an API for PCI compliance so an ISO can place SAQ completion where it belongs in the merchant journey. Partners can offer CAT by REST API, MCP integration for AI agents and bank chatbots, an embeddable white-label iframe, or a platform redirect with hand-off and return.

The flow starts with merchant creation and payment methods. Merchants describe how they take payments in plain words. CAT determines the likely SAQ type, asks a plain-English follow-up question when needed, then runs only the questions that fit that business and payment method.

After review and digital signature, the merchant gets the official PCI SSC SAQ and Attestation of Compliance PDFs filled in. For the ISO, portfolio endpoints show invited, started, in progress, completed, expiring, and expired merchants, with CSV export and signed webhooks for status changes.

If a merchant uses Authorize.Net, CAT can read how that merchant takes payments so the assessment starts from accurate facts, while the merchant still reviews and answers everything. For teams evaluating implementation options, the PCI compliance API overview, integration docs, OpenAPI specification, and Postman workspace show the integration details.

A simple way to roll this out

You do not need to redesign your entire onboarding stack at once. Start by deciding where PCI should appear in your merchant journey: inside your app, inside an onboarding dashboard, inside a support-assisted workflow, or as a branded handoff step.

Then map the minimum flow: create the merchant, add each payment method, let the merchant answer the assessment, collect the signature, and store the resulting status back in your CRM or onboarding system through signed webhooks or API polling.

The key is to make PCI part of the definition of a fully onboarded merchant, not a separate campaign that starts later. When SAQ completion is tied to setup, activation, and annual renewal tracking, it becomes an operating process instead of a collections problem.

If you want to test the approach, start with the free sandbox. You can also review the API examples on GitHub to see how the flow can fit into your onboarding experience.

Common questions

Should an ISO require PCI SAQ completion before a merchant can process?

That decision sits with the ISO, sponsor bank, and acquirer process. Operationally, collecting the SAQ during onboarding is usually easier because payment details are current and the merchant is already completing required setup steps.

What if a merchant accepts cards in more than one way?

Treat each payment method separately. A merchant may need more than one SAQ because an in-person terminal flow and an e-commerce flow can fall into different SAQ categories.

Does embedded checkout always mean SAQ A-EP?

No. Since the January 2025 revision of SAQ A, a merchant using card fields embedded from a compliant payment provider can use SAQ A rather than A-EP, provided the site is protected against script attacks or the provider confirms this in writing. The important question is who supplies the card form, not simply whether the fields appear on the merchant's website.

Can CAT decide the final SAQ a merchant must file?

CAT determines the likely SAQ type from the merchant's payment description and follow-up answers, but the acquirer decides which SAQ the merchant must file. CAT is a PCI DSS compliance platform for running the assessment flow and producing the filled SAQ and AoC documents.

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.