PCI compliance for PayFacs: sub-merchant validation inside your own platform

Your platform lets small businesses start taking cards in minutes, and the PCI DSS section of your sponsor agreement applies to every one of them. Here is who is responsible for what, how your product shapes each sub-merchant's questionnaire, and how to validate sub-merchants without a separate compliance portal.

Who is responsible for what

• The sponsoring acquirer is responsible to the card brands for both the payment facilitator and its sub-merchants, and Visa expects it to make sure proper due diligence happens when sub-merchants are signed.
• The PayFac contracts with sub-merchants and, in Visa's words, monitors their compliance with the card-brand rules. It also has to be PCI DSS compliant itself, as a service provider, and the card brands tie its registration to that validation.
• The sub-merchant is a merchant in its own right. Visa states that all merchant requirements apply equally to sponsored merchants, so each one has its own PCI DSS obligations and signs its own Attestation of Compliance.

In practice the PayFac sits in the middle: it collects sub-merchant validation within what the acquirer requires, and reports upward. Your sponsor agreement sets the details.

Why sub-merchant PCI is harder for a PayFac

• Speed. Your onboarding is fast and self-serve; a compliance step that feels like paperwork is where small businesses stop.
• They don't think of themselves as merchants. A yoga studio signed up for your software, not a card-brand program. Auditor language goes unanswered.
• A second destination. A separate portal with its own login and brand is one more place to go, and one more email to ignore.
• Payments outside your platform. A sub-merchant that also keys phone orders elsewhere, or runs a second terminal, has another channel to cover.

Your integration shapes your sub-merchants' SAQ

Under PCI DSS v4.0.1 there are nine merchant Self-Assessment Questionnaires, and which one applies follows from how a business takes cards. For a PayFac, much of that is decided by the product you offer, so a well-designed integration keeps sub-merchants on a short questionnaire.

What the sub-merchant uses	SAQ it usually points to
Your hosted payment page, or your payment fields embedded in their checkout	SAQ A, provided the site meets SAQ A's criterion on script attacks (see SAQ A vs SAQ A-EP)
A card form their own website builds, which then sends card data to you	SAQ A-EP
Card numbers typed into your virtual terminal in a browser	SAQ C-VT
Terminals in a PCI-listed point-to-point encryption (P2PE) solution	SAQ P2PE
A phone or tablet with a secure reader in a PCI-listed SPoC solution	SAQ SPoC

Summaries only; each SAQ has formal eligibility criteria published by the PCI Security Standards Council, and the acquirer decides which SAQ applies.

Your own compliance matters too. PCI DSS Requirements 12.8 and 12.9 cover how merchants manage service providers and how service providers support their customers' compliance. Sub-merchants rely on your Attestation of Compliance and on a clear responsibility matrix showing which requirements you cover and which remain theirs; publish it where they can find it.

What a good PayFac PCI program looks like

• Validation is a step in onboarding, or a dashboard task right after it, with a deadline your acquirer accepts.
• Every channel, on or off your platform, gets the right SAQ.
• The output is the official PCI SSC SAQ and AoC, signed by the sub-merchant, under your brand.
• Status lands in your risk systems automatically, and you know who is coming due for renewal.
• You can hand your acquirer a portfolio report without a project.

How an API approach works for a PayFac

An API for PCI compliance puts those steps inside your platform. At boarding, your systems create the merchant and add a payment method for each way it takes cards, described in plain words; the SAQ for each is determined automatically, with a plain-English follow-up when needed.

• Delivery: embed the white-label iframe in your dashboard, build your own screens on the REST API (OpenAPI 3.1), use a platform redirect, or let an AI agent run the assessment through the MCP server.
• Plain-English questions written for that business and payment method. The sub-merchant reviews every answer, signs digitally and gets the official SAQ and AoC PDFs.
• Status in your systems: signed webhooks report changes to your risk or onboarding service.
• Reporting upstream: a portfolio funnel (invited, started, in progress, completed, expiring, expired) with a CSV export for your acquirer, plus annual renewal tracking.

More in PayFac PCI validation without a separate portal, embedding SAQ completion in onboarding and the PCI compliance API overview.

What Compliance Assessment Tool does not do

CAT handles your sub-merchants' merchant SAQs. It does not perform your own service-provider assessment, is not a Qualified Security Assessor, does not scan networks (sub-merchants whose SAQ requires quarterly scans need an Approved Scanning Vendor), and does not measure fraud or disputes.

Questions to ask before you choose an approach

• What does our sponsor agreement require us to collect, by when, and in what reporting format?
• Which SAQ does our standard integration point to, and how do we catch sub-merchants who take cards other ways?
• Can the sub-merchant finish without leaving our product or seeing another company's brand?
• How does status reach our risk systems, and how will we know who expires next quarter?
• Can our engineers try it today in a sandbox?

Also see: Merchant PCI programs for sponsor banks · A PCI compliance API for ISOs.

Common questions

Is a PayFac responsible for its sub-merchants' PCI compliance?

Largely, yes. Visa describes a payment facilitator as monitoring its sponsored merchants' compliance with the Visa Rules, and says all merchant requirements apply equally to sponsored merchants. The sponsoring acquirer remains responsible to the card brands for both the PayFac and its sub-merchants, so it will set out in your agreement what you must collect, track and report.

Does every sub-merchant need to complete its own SAQ?

Each sub-merchant is a merchant under card-brand rules and has its own PCI DSS obligations. Which sub-merchants must formally validate, with which form and by when, is set by your acquirer and your agreement with it. Sub-merchants that take cards only through a PayFac's hosted checkout or embedded fields often qualify for SAQ A, one of the shortest.

Does the PayFac need its own PCI DSS validation?

Yes. A PayFac stores, processes or transmits cardholder data, or can affect its security, for its sub-merchants, so it validates its own PCI DSS compliance as a service provider. The card brands and your acquirer set how it validates, for example a QSA assessment or a self-assessment.

Which SAQ does a sub-merchant using our hosted checkout need?

Usually SAQ A, when the entire card form comes from your PCI DSS compliant hosted page or embedded fields and the sub-merchant meets SAQ A's eligibility criteria, including the criterion on protecting its site from script attacks. Any other way the sub-merchant takes cards, such as a terminal or phone orders, has to be covered too. The acquirer decides which SAQ applies.

Can sub-merchant PCI validation happen inside our own onboarding flow?

Yes. With an API for PCI compliance, your platform creates the sub-merchant, adds each payment method and starts the assessment. The sub-merchant answers plain-English questions in your dashboard, through an embedded iframe or your own screens on the REST API, and signs; you get the filled-in SAQ and AoC and a signed webhook.

How do we report sub-merchant PCI status to our acquirer?

Agree the format and frequency with your acquirer first. With Compliance Assessment Tool, portfolio endpoints show how many sub-merchants are invited, started, in progress, completed, expiring or expired, and the same view exports as a CSV you can send upstream.

Sources

• Visa: Visa's Payment Facilitator Model
• Visa: Account Information Security Program and PCI
• PCI SSC Community Meeting 2025: Payment Facilitators and PCI DSS Compliance
• PCI SSC Document Library (PCI DSS v4.0.1 and the SAQs)
• PCI SSC FAQ 1588: SAQ A eligibility criteria for scripts

This page is general information, not legal advice. Card-brand rules and your sponsor or acquirer agreements set your obligations and each merchant's validation requirements; the acquirer decides which SAQ applies. Compliance Assessment Tool facilitates merchant PCI DSS self-assessment under PCI DSS v4.0.1. It is not a Qualified Security Assessor and does not certify or guarantee compliance. Third-party names are trademarks of their owners.