Compliance Assessment Tool
Home › Blog

How a PayFac validates PCI across many sub-merchants without a separate compliance portal

October 28, 2026 · Compliance Assessment Tool

Short answer. A PayFac can validate PCI across many sub-merchants by embedding the assessment inside its own onboarding, dashboard, or support flow instead of sending merchants to a separate portal. The key is to determine the right SAQ for each payment method, ask plain-English questions based on how that merchant actually takes cards, collect the signature, and keep portfolio status synced back into the PayFac’s own systems.

Why separate PCI portals create friction for PayFacs

PayFacs usually want one merchant experience, one brand, and one source of truth for onboarding and ongoing account management. A separate PCI portal breaks that pattern. The merchant leaves your flow, sees a different interface, and often loses the context of why they are being asked these questions.

When PCI validation sits somewhere else, operations teams also lose control. Status updates have to be chased down, support teams have to answer questions without seeing the same screen as the merchant, and product teams end up stitching together reminders, exports, and manual follow-up.

The result is familiar: some sub-merchants complete quickly, many stall in the middle, and others never start because the questionnaire feels disconnected from the way they actually accept payments. That problem gets worse when the wrong SAQ is selected, because merchants either face too many questions or not enough.

What validation needs to look like at PayFac scale

At PayFac scale, PCI validation needs to behave like part of your product, not like a side program. The merchant should move from onboarding or account settings into a PCI flow that already knows who they are, how they take payments, and what needs to happen next.

That means starting from payment methods, not from a long form with compliance terms. A sub-merchant may take cards in more than one way, such as a browser-based virtual terminal plus an online checkout, or a counter terminal plus an invoice link. Each payment method may map to a different SAQ, and each one should be handled separately.

It also means the PayFac needs portfolio visibility without asking merchants or support teams for updates. You need to see who has been invited, who has started, who is in progress, who has completed, and who is coming up for renewal, all inside your own operating rhythm.

A practical model: keep the experience in your platform, push PCI through an API

The cleanest approach is to treat PCI validation as infrastructure. Your platform creates the merchant record, adds the merchant’s payment methods, runs the assessment, collects the digital signature, and stores the completion status in your own systems while the official SAQ and AoC documents are generated in the background.

We built CAT around that model. CAT is a PCI DSS compliance platform that PayFacs, ISOs and banks can deliver in four ways to integrate: REST API, MCP for AI agents and bank chatbots, an embeddable white-label iframe, or a redirect hand-off and return flow. For PayFacs that do not want a separate portal, the usual fit is the API or white-label iframe.

The core workflow is straightforward. The merchant describes in plain words how they take payments. AI determines which of the 9 SAQ types applies, asking a plain-English follow-up question when needed. Then every question is written for that business and payment method in plain English, and each answer shapes the next. At the end, the merchant reviews, signs digitally, and receives the official PCI SSC SAQ and Attestation of Compliance PDFs filled in.

If you want to evaluate the implementation detail, the PCI compliance API overview gives the high-level model, the Integration docs cover the workflow, and the full OpenAPI is published at OpenAPI specification.

How this works without creating a second merchant destination

“Without a separate portal” does not always mean “build every screen yourself.” For many PayFacs, it means the merchant never feels handed off to a different provider relationship. The assessment can appear inside your product through a white-label iframe, or you can use the API to build the flow directly into your own UI.

Either way, your brand stays in front of the merchant and the relationship stays with you. That matters operationally because support, risk, boarding, and account management can all refer to the same merchant journey. It also matters for trust: merchants are more likely to complete a PCI task when it appears as a normal part of your existing service experience.

For teams that want automation beyond a merchant-facing screen, an MCP integration can let an AI agent or chatbot run the assessment flow. That can be useful when your support or onboarding experience already includes a conversational layer and you want PCI questions to happen there rather than in a separate destination.

If your sub-merchants use Authorize.Net, CAT also has an Authorize.Net connection that reads how a merchant takes payments so the assessment starts from accurate facts. The merchant still reviews and answers everything, but the process starts with better context instead of guesswork.

What your operations team needs after launch

PCI validation is not only a merchant questionnaire problem. It is also a portfolio management problem. Once you have many sub-merchants, you need to know who is invited, who is stuck, who is complete, and who is nearing expiry without building side spreadsheets.

That is why status reporting and renewal handling matter as much as the assessment itself. CAT provides portfolio endpoints that show the funnel across merchants, supports CSV export, and supports bulk CSV invites. Signed webhooks report status changes so your internal systems stay current when an assessment is started or completed.

For PayFac operations teams, this changes the day-to-day work. Instead of logging into a separate compliance portal to check progress, the data can be pulled into your CRM, merchant dashboard, or internal operations tooling. Reminders and task creation can happen from your own systems, based on the same status your teams already use for onboarding and servicing.

This model also helps with merchant support. When a sub-merchant asks why they are being asked certain questions, your team can see the payment method, the stage of the assessment, and what still needs to be completed. That is much easier than supporting a process that lives in another vendor’s portal.

How to choose the right scope before you build

Before you integrate any PCI flow, make sure your product and operations teams agree on a few basics. First, decide where PCI should appear in the merchant journey: during onboarding, after activation, in account settings, or through a support-assisted flow. Second, decide whether you want an embedded experience, a direct API build, or a hand-off model.

Then focus on SAQ accuracy. The biggest practical failure in merchant PCI programs is starting with the wrong SAQ path. A merchant’s answers should reflect how they actually take cards, and a merchant with more than one payment method may need more than one assessment. Our guide on Which SAQ do I need? is a useful refresher, and e-commerce teams should pay close attention to the January 2025 SAQ A revision explained in SAQ A vs SAQ A-EP.

For example, a merchant whose checkout uses card fields embedded from a compliant payment provider 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. PCI SSC also addresses that script question directly in PCI SSC FAQ 1588. The details matter because the wrong branch creates unnecessary friction for the merchant and cleanup work for your team later.

If you are comparing delivery models for your own program design, PCI program alternatives is a practical place to start. And if you want to test the workflow quickly, we offer a free sandbox at Free sandbox.

Common questions

Can a PayFac validate PCI without sending merchants to a separate compliance website?

Yes. The usual approach is to embed the experience in your own platform with an iframe or build the workflow into your own UI over an API. The important part is that the merchant can complete the assessment, sign digitally, and finish the process without feeling pushed into a disconnected relationship.

Does one sub-merchant always have just one SAQ?

No. A sub-merchant can have more than one payment method, and each payment method can require its own SAQ. For example, an in-person terminal flow and an online checkout flow should be treated separately so the right questionnaire is used for each.

How does a PayFac keep PCI status in sync with its own systems?

Use status webhooks and portfolio endpoints so your CRM, onboarding system, or merchant dashboard stays current. That lets your teams see who has completed, who is in progress, and who is nearing expiry without checking a separate portal manually.

Can CAT decide the final SAQ type for the merchant?

CAT can determine the likely SAQ type from the merchant’s description and follow-up answers, which helps the process start on the right path. But the acquirer decides which SAQ a merchant must file, and CAT does not replace that decision.

What is the fastest way for a PayFac to test this model?

Start in a sandbox and run a few realistic merchant scenarios with different payment methods. If your team wants implementation examples, the docs, OpenAPI spec, Postman workspace, and GitHub examples are the quickest way to see how the flow would fit your platform.

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.