Starting an ISO? Your merchant PCI program from merchant #1

You have a sponsor bank conversation going, a processor picked out, and a gateway your merchants will use. Somewhere in the sponsor agreement there is a section on PCI DSS. Here is what that section usually means in practice, and how to have a working merchant PCI program before your first merchant is boarded.

The pieces of a new ISO, and where PCI fits

An Independent Sales Organization (ISO) signs up merchants to accept cards on behalf of an acquirer. To do that you assemble a handful of relationships, and merchant PCI compliance runs through most of them.

• Sponsor bank. A card-brand member bank that sponsors your access to the networks. The sponsor carries ultimate responsibility to Visa and Mastercard for the merchants you board, which is why its agreement with you sets your PCI obligations.
• Processor and acquirer relationships. The processor authorizes and settles transactions; many new ISOs sign with an acquiring processor that brings its own sponsor bank. Either way, the acquirer is the party the card brands hold accountable for merchant compliance.
• Card-brand registration. You don't register yourself. Your sponsor or acquirer registers you with Visa and Mastercard as a third-party agent or service provider, after its own due diligence on your business. Expect registration fees and annual renewals; your sponsor will explain its process.
• Gateway. Card-not-present merchants, and many card-present ones, connect through a gateway such as NMI or Authorize.Net. How a merchant's gateway is set up (a hosted payment page versus card fields on the merchant's own site, for example) largely decides which SAQ the merchant needs.
• Underwriting and risk. Know-your-customer and know-your-business checks, a MATCH list check, and approving each merchant's processing profile. Underwriting is also the natural moment to capture how the merchant will take cards.
• Merchant onboarding. The application, boarding the merchant account, and deploying terminals or gateway credentials.
• The merchant PCI program. How every boarded merchant validates PCI DSS compliance each year, how you track it, and what you report upstream. Acquirers and sponsor banks expect you to have this from the start.

One more question to settle early: whether your own company is in PCI scope. If you store, process or transmit cardholder data, or can affect its security (by hosting payment pages or managing merchants' terminals, for instance), you may need to validate as a service provider yourself. Ask your sponsor bank, and a Qualified Security Assessor (QSA) if needed.

ISO or PayFac?

An ISO refers merchants to an acquirer, and each merchant gets its own merchant account. A payment facilitator (PayFac) is itself the acquirer's merchant: it onboards sub-merchants under its own master account and contracts with them directly. That means a PayFac takes on work an acquirer would otherwise do for each sub-merchant, including underwriting, funding, risk monitoring and making sure sub-merchants meet card-brand rules. That includes keeping track of each sub-merchant's PCI validation status. A PayFac must also validate its own PCI DSS compliance as a service provider. The merchant PCI program below applies to both models; for a PayFac it is simply more clearly your job.

What a merchant PCI program has to do

1. Find the right SAQ for each merchant and payment method

Most small and mid-size merchants validate with a Self-Assessment Questionnaire (SAQ); the largest merchants are assessed by a QSA instead. Under PCI DSS v4.0.1 there are nine merchant SAQs, and the right one depends on how the merchant takes cards. A merchant with a counter terminal and an online store has two channels to cover, and your acquirer decides whether it wants one combined SAQ or one per channel.

SAQ	Who it is for
SAQ A	Online, mail or phone-order merchants that fully outsource the payment page to a PCI DSS-compliant provider (hosted checkout, redirect or iframe), so card data never touches their systems.
SAQ A-EP	E-commerce merchants whose own website builds the card form (direct post, or a script reading their own card boxes), even though card data goes straight to the payment provider.
SAQ B	Merchants using imprint machines or standalone terminals that dial out over a phone line, with no electronic card data storage.
SAQ B-IP	Merchants using standalone, PCI-approved terminals that connect to the processor over the internet and are not connected to other systems.
SAQ C	Merchants whose payment application (for example a POS system) runs on systems connected to the internet, with no electronic card data storage.
SAQ C-VT	Merchants who key card details, one transaction at a time, into a third-party virtual terminal in a web browser.
SAQ D	Every merchant that does not fit a shorter SAQ, including any that store card data electronically or accept it on their own website.
SAQ P2PE	Merchants that take cards only on terminals that are part of a PCI-listed point-to-point encryption (P2PE) solution.
SAQ SPoC	Merchants using a PCI-listed software-based PIN entry on COTS (SPoC) solution: a phone or tablet paired with a secure card reader.

Summaries only. Each SAQ has formal eligibility criteria published by the PCI Security Standards Council; see the plain-English SAQ guide for each one.

2. Get the SAQ and AoC completed and signed

The merchant answers the SAQ and signs an Attestation of Compliance (AoC), the document that states their compliance status. These are the official PCI SSC forms, and they are what your acquirer and its auditors expect to see. The hard part is not the form; it is getting a restaurant owner to pick the right one and finish it.

3. Track annual renewals and quarterly scans

Validation is annual, so every AoC has a date that matters. SAQ A, A-EP, B-IP, C and D also include quarterly external vulnerability scans by a PCI SSC Approved Scanning Vendor (ASV). Whether a particular merchant needs scans is stated in their SAQ. Your program needs to know which merchants need scans and whether they have current, passing ones.

4. Report portfolio status upstream

Your sponsor bank or acquirer will want to know how much of your portfolio has validated: who is compliant, who is in progress, who has not started and who is about to expire. Agree the format and frequency early, so reporting is an export, not a project.

5. Handle non-compliance

Many ISOs and processors charge merchants a monthly PCI non-compliance fee until they validate, and some also charge an annual program fee. Whether you charge one, how much, and how you disclose it is a business and legal decision; settle it with your sponsor bank and your counsel, and put it plainly in your merchant agreement. Whatever you decide, the fee works best alongside an easy way for merchants to finish. Merchants who search for the fee on their statement land on pages like this explanation of the PCI non-compliance fee.

Build or buy?

Building your own merchant PCI program is possible, but it is more than a questionnaire. You would need:

• Eligibility logic for all nine SAQs, applied to every payment method a merchant uses.
• Questions a non-technical owner can answer, mapped back to the PCI DSS requirements in each SAQ.
• Output on the official PCI SSC SAQ and AoC forms, signed by the merchant.
• Updates whenever PCI SSC revises the standard or the SAQs, as it did moving from v3.2.1 to v4.0 and then v4.0.1.
• Reminders, renewals, scan tracking, portfolio reporting and merchant support.
• Security for a system that holds your merchants' attestations.

That is engineering and compliance time that doesn't go into boarding merchants, so most ISOs buy. When you compare vendors, ask what share of invited merchants actually complete, how they pick the SAQ for merchants with more than one channel, whose brand the merchant sees, how you integrate, how you see and export portfolio status, and what it costs and who pays. The full list of criteria and questions is in our guide to choosing a merchant PCI compliance program.

Fraud and disputes: Visa's Acquirer Monitoring Program (VAMP)

PCI DSS is about protecting card data. Your sponsor bank will also watch a second risk from day one: fraud and disputes across your portfolio. Since 2025, Visa measures both through the Visa Acquirer Monitoring Program (VAMP), which replaced Visa's separate fraud and dispute monitoring programs with a single measure.

• The VAMP ratio adds a merchant's reported fraud (TC40) and disputes (TC15) and divides by its settled card-not-present transactions.
• Merchants in the US are flagged as "Excessive" at a VAMP ratio of 1.5% (from April 1, 2026), and a separate threshold flags excessive card testing (enumeration).
• Acquirers are measured on their whole portfolio, with "Above Standard" and "Excessive" levels set far lower, at 0.50% and 0.70%. Every ISO's merchants count toward their sponsor bank's number, so expect your sponsor to push monitoring, and any fees, down to you.

Visa updates thresholds and fees, so check the current program rules with your acquirer. PCI and VAMP overlap more than they seem: card testing usually hits e-commerce checkouts, and a merchant that uses a hosted payment page and keeps its checkout secured (the payment-page requirements in SAQ A and A-EP) is a harder target. Plan to monitor fraud and dispute ratios per merchant, and treat a sudden rise as a reason to review that merchant's setup, PCI validation included.

A day-one checklist

1. Read the PCI section of your sponsor and acquirer agreements: what you must track, what you must report, and how often.
2. Decide how merchants will validate (your own program, a vendor's, or the acquirer's) and who pays for it.
3. Find out whether your own company is in PCI scope as a service provider.
4. At underwriting, capture every way each merchant takes cards: terminal model and how it connects, gateway and integration type, virtual terminal, phone and mail orders.
5. Where you choose the setup, prefer options that keep merchants on a short SAQ, such as a hosted payment page or a PCI-listed P2PE solution.
6. Make PCI validation a step in onboarding, with a deadline your acquirer accepts, rather than a separate chase later.
7. Line up an ASV for merchants whose SAQ requires quarterly scans.
8. Keep each merchant's SAQ, AoC and validation date on file, and know when each one expires.
9. Send renewal reminders well before expiry, and re-validate merchants who change how they take payments.
10. Decide your non-compliance policy and disclose any fee clearly in your merchant agreement.
11. Agree the portfolio report format with your sponsor bank or acquirer.
12. Monitor each merchant's fraud and dispute ratio against Visa's VAMP thresholds, and agree with your sponsor what happens when one rises.
13. Keep a due-diligence file on every vendor in the chain: Trust Center, security overview, DPA and sub-processors.

How Compliance Assessment Tool fits

CAT is a PCI compliance engine for ISOs, acquirers and PayFacs, under your brand. Each merchant describes how they take payments in their own words. CAT asks a follow-up only when it needs one, picks the right SAQ for each payment method (all nine merchant SAQs under PCI DSS v4.0.1), and asks every question in plain English, written for that business and that payment method. The merchant reviews and confirms every answer, signs, and gets the official PCI SSC SAQ and AoC, filled in.

• Launch your way: bulk invites with branded emails, a platform redirect, an embedded white-label iframe, the REST API, or an MCP server for AI agents.
• Portfolio visibility: a portfolio API, CSV export for your sponsor bank, signed webhooks, and annual renewals that carry last year's answers forward.
• Authorize.Net connection: with the merchant's API credentials, CAT reads the account's market types and recent transactions to suggest how the merchant takes payments. The credentials are used once and never stored.
• Pricing: $25 per completed assessment, and a free sandbox for your engineers.

CAT does not provide ASV scans or breach insurance; pair it with a scanning vendor if your merchants need scans. More detail is on the PCI compliance API page.

Common questions

Do I need a PCI program before boarding my first merchant?

Your sponsor bank or acquirer decides, but expect to be asked how your merchants will validate PCI DSS compliance before or as you start boarding. Card-brand rules hold acquirers responsible for their merchants' compliance, and acquirers pass much of that work to the ISOs that board merchants for them. It is far easier to make PCI validation part of onboarding from merchant #1 than to chase a whole portfolio later.

Who is responsible for a merchant's PCI compliance at an ISO?

The merchant is responsible for its own compliance and signs its own Attestation of Compliance. The acquirer is responsible to the card brands for making sure its merchants comply, and usually delegates tracking and follow-up to the ISO that boarded them. Your sponsor or acquirer agreement spells out exactly what falls to you.

Which SAQ does a merchant using a countertop terminal need?

It depends on how the terminal connects. A terminal that dials out over a phone line is usually SAQ B; a standalone terminal that connects over the internet is usually SAQ B-IP; a terminal that is part of a PCI-listed point-to-point encryption (P2PE) solution qualifies for SAQ P2PE; and a terminal attached to a POS system or computer is usually SAQ C. If the merchant also takes cards online or by phone, each of those channels has to be covered too.

How often do merchants re-validate PCI compliance?

Every year for the SAQ and AoC, plus quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) where the merchant's SAQ requires them. An acquirer may also ask a merchant to re-validate after a significant change, such as a new terminal or a new way of taking payments online.

Can a new ISO white-label a PCI program?

Yes. Several providers offer merchant PCI compliance programs under the ISO's own brand, from managed portals to API-first platforms such as Compliance Assessment Tool. Confirm that the output is the official PCI SSC SAQ and Attestation of Compliance, and that your acquirer accepts it.

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

Generally, yes. A payment facilitator contracts with its sub-merchants directly, so it takes on responsibility for making sure they comply with card-brand rules, including PCI DSS, and it must also validate its own PCI DSS compliance as a service provider. Your sponsor agreement sets the details.

What is Visa VAMP and does it affect a new ISO?

The Visa Acquirer Monitoring Program (VAMP) measures fraud and disputes. A merchant's VAMP ratio is its reported fraud (TC40) plus disputes (TC15), divided by its settled card-not-present transactions; US merchants are flagged as Excessive at 1.5% from April 1, 2026. Acquirers are measured across their whole portfolio at much lower levels, so a sponsor bank will expect its ISOs to monitor their merchants and may pass VAMP fees down. Check current thresholds with your acquirer, as Visa updates them.

Does my ISO itself need to be PCI DSS compliant?

If your company stores, processes or transmits cardholder data, or can affect its security (for example by hosting a payment page or managing merchants' terminals or gateway settings), it may need to validate as a service provider. An ISO that only refers merchants and never handles card data usually has a lighter obligation. Confirm with your sponsor bank, and a Qualified Security Assessor if needed.

This page is general information, not legal advice. Your sponsor bank and acquirer agreements, and the card-brand rules, set your obligations and each merchant's validation requirements; talk to your sponsor bank and counsel. Compliance Assessment Tool facilitates merchant PCI DSS self-assessment. It is not a Qualified Security Assessor and does not certify compliance. Third-party names are trademarks of their owners.