Payment facilitator, ISO or partner: how platforms offer payments

Why the model matters

Whether you are weighing payment facilitator vs ISO or a PayFac-as-a-Service provider, the card networks don’t go by what an arrangement is called. They go by what your platform does. Three questions decide your role.

• Who signs your customers as merchants? The acquirer, the card network member that contracts with merchants, can sign them directly, through a sales agent or through a payment facilitator.
• Who touches the funds? Under Visa’s rules, receiving settlement funds for your customers is one of the things that makes an entity a payment facilitator.
• Who is liable when something goes wrong? Disputes, fraud and a customer that closes while owing money all land somewhere. Network rules and contracts decide where.

Your answers set the registrations you need, the onboarding and monitoring work you take on, your tax reporting and, in some states, whether you need a money transmission license. No model removes risk; each one only moves it.

ACH has its own rule book, the Nacha Rules, and its own roles. Those come near the end of this guide.

PayFac vs ISO: payment models compared

Here is how three common ISV (independent software vendor) payment models compare; the sections below explain each role. Vendor arrangements vary, so treat the PayFac-as-a-Service column as typical, not guaranteed, and check every row against your contracts.

ISOs: the acquirer’s sales agents

An independent sales organization (ISO) finds and signs merchants for an acquirer. In Visa’s description, an ISO acts as the acquirer’s agent, so a merchant that signs a contract through an ISO is signing with the acquirer.

Visa also says what an ISO does not do: process transactions, receive settlement funds or access account data. An ISO that processes transactions is classified as a Third Party Servicer instead, though an ISO may resell or white-label a payment gateway run by another registered provider.

The Mastercard Rules dated June 2, 2026 describe a similar role: soliciting merchants and processing their applications, customer service without access to account data, merchant training and terminal deployment.

For a software platform, the closest version of this model is referral. You send your customers to a provider, they sign merchant agreements with the acquirer, and their settlement funds don’t pass through you. If your platform itself solicits merchants as an acquirer’s agent, that is an ISO role, and both networks expect registration: Visa for every third-party agent, Mastercard for every Service Provider.

Merchant Servicers and registration

Software that sits in the payment flow without signing merchants or touching funds still has a place in the rules. Visa’s third-party agent guidance, dated October 2026, calls a provider that the merchant contracts with directly a Merchant Servicer. Its listed functions include payment gateways and checkout software, and embedded-payment or vertical SaaS platforms that embed, configure or control payment acceptance.

Visa’s registration requirement covers Merchant Servicers too, and it happens through an acquirer. A provider doesn’t have to handle Visa account data to be in scope, and one provider can hold several third-party agent roles at once.

A Merchant Servicer may not sign merchant agreements for the acquirer or receive settlement for the seller, and sellers must tell their acquirer which Merchant Servicers they use. Under Visa’s guidance, moving funds to merchants requires classification as a payment facilitator or another acquiring category.

If your software embeds or controls card acceptance for your customers, your platform may fall within Merchant Servicer scope even in a referral model, so confirm your status with the acquirer or provider your customers sign with. Ask any gateway provider which network registrations and PCI DSS validation it holds.

Payment facilitators (PayFacs)

A payment facilitator (PF, often called a PayFac) signs merchants on an acquirer’s behalf, receives settlement for them, or both. Visa defines a PF as an entity that contracts with an acquirer to deposit transactions for a sponsored merchant, receive settlement for it, or contract with the acquirer on its behalf. Doing any one of these makes an entity a PF. Visa also calls PFs master merchants or merchant aggregators.

The Mastercard Rules define a PF as a Service Provider that an acquirer registers to help it acquire transactions from sponsored merchants, also called submerchants. Mastercard publishes a list of registered PFs. This guide says “sub-merchant” for both networks’ terms.

Who stays liable

Under both networks, the sponsoring acquirer stays liable for its PFs and their sub-merchants. Visa treats a sub-merchant as a merchant of its PF’s acquirer. Mastercard lets the acquirer hand the PF tasks such as verifying, paying and monitoring sub-merchants, but the acquirer remains fully responsible if the PF fails, and settlement funds the PF can access may be used only to pay sub-merchants.

The risk still reaches the PF by contract. Visa requires the PF agreement to make the PF liable for its sub-merchants’ acts, omissions and cardholder disputes, and financially liable for each transaction and each disputed transaction or credit. The PF must also make sure its sub-merchants comply with PCI DSS and the PCI Software Security Framework.

How a PF is registered

A PF doesn’t register itself; its acquirer does. Visa must confirm the registration, including the acquirer’s attestation of due diligence, before the PF submits transactions, and the acquirer must be in good standing and meet minimum risk-rating and equity standards. Neither the PF nor its sub-merchants can be listed on the Visa Merchant Screening Service (VMSS).

Mastercard requires the acquirer to register the PF in its My Company Manager application, with validation within 30 days and once each calendar year after that. Neither network lets a PF sponsor another PF.

What a PF owes its sub-merchants

Mastercard spells out the ongoing duties of a PF to the merchants it signs.

• Valid transactions only, from bona fide cardholders.
• Compliance and training, so sub-merchants follow the network standards.
• Records, including each sub-merchant’s name, address and website.
• Ongoing monitoring, watching sub-merchant activity to deter fraud.
• Paying sub-merchants, covering all their transactions. The duty isn’t met until the sub-merchant actually receives the funds, though the agreement may let the PF hold back amounts for chargeback reserves.

In the United States, Mastercard also requires a PF to give each sub-merchant a separate fee disclosure that explains in plain terms how every fee is calculated, and at least 30 days’ notice before any new or increased fee.

Sub-merchant volume thresholds

Both card networks pull large sub-merchants into a direct contract with the acquirer, but their thresholds differ by a factor of ten.

Visa: USD 1 million. Under the Visa Core Rules, once a sub-merchant’s annual Visa volume exceeds USD 1 million, the acquirer must sign a direct merchant agreement with it, before any processing for a new sub-merchant or within two years for an existing one. The PF may keep providing payment services, including settlement. Two exceptions apply.

• Long-standing relationships, where the PF has held the sub-merchant for at least two years with the same acquirer, reports its volume, disputes and fraud, and stays under the acquirer’s oversight.
• Exempt categories, listed by merchant category code below.

Neither exception applies to parties flagged in Visa risk programs or to certain high-risk merchant types.

Mastercard: USD 10 million. Under the Mastercard Rules, as of October 2026, a sub-merchant above USD 10 million in combined Mastercard and Maestro annual volume needs a direct merchant agreement with the acquirer, unless its category is exempt or the Sponsored Merchant Threshold Conditions are met. Those conditions include the PF’s registration as a Network Enablement Partner, read-only acquirer access to the PF’s systems, and acquirer review of at least 5% of the PF’s newly onboarded sub-merchants each month. The acquirer may still require a tri-party agreement.

Exempt categories. Both networks treat a few verticals as special PF territory and exempt them from the threshold by merchant category code (MCC). The exempt codes include these.

The lists go code by code, so check that your customers’ MCC is on them before you rely on an exemption.

Marketplaces and Platform Merchants

Some platforms ask whether they count as a marketplace instead. Visa’s definition is narrow. A Marketplace brings cardholders and retailers together on an e-commerce site or app under its own brand, shown more prominently than the retailers’. It handles payments and refunds, receives settlement for its retailers and is financially liable for disputes.

Visa also caps foreign retailers’ volume and bars some merchant types, including travel agents, High-Integrity Risk merchants and charitable social service organizations such as crowdfunding merchants. A platform whose customers bill under their own names doesn’t fit that test.

The current Mastercard Rules have no separate marketplace type. They use the Platform Merchant, which hosts third-party sellers on its online platform and accepts cards for their sales. It must verify each seller and its principal owners, meet anti-money-laundering and sanctions screening requirements, contract with each seller before submitting its transactions, set fraud-loss controls, keep monitoring and understand its liability for its sellers’ disputes.

PayFac-as-a-Service

PayFac-as-a-Service is a vendor term, not a network category. Neither the Visa Core Rules (April 18, 2026 edition) nor the Mastercard Rules (June 2, 2026) use “PayFac” or “PayFac-as-a-Service”.

Vendors apply it to arrangements where a provider supplies the payments infrastructure and handles work such as underwriting, PCI DSS, anti-money-laundering and know-your-customer checks, fraud screening and reporting, with risk shared with or handled by the provider. Typically the provider is the registered payment facilitator and your platform is not, but the label means different things to different vendors, so read the contract rather than the name.

The network definitions give you a test. By Visa’s definitions, a platform that neither signs merchant agreements for the acquirer nor receives settlement is generally not itself a PF. How much loss liability your platform carries depends on the contract. Ask who the PF of record is, who receives settlement funds, and what happens if one of your customers runs up disputes or losses and then closes.

Becoming an acquirer

At the far end, a platform could try to bring acquiring in-house. That means becoming a card network licensee or working through one. Mastercard limits its Principal and Affiliate customers to financial institutions or other entities authorized to engage in financial transactions, such as making loans, taking deposits or issuing prepaid accounts or e-money, and it requires business plans acceptable to Mastercard.

No entity may take part until it is approved, has signed the applicable licenses and has paid the associated fees. Visa’s public rules leave membership eligibility to its charter documents, and Visa’s guidance says acquirers that sponsor PFs or marketplaces must meet additional minimum equity standards.

Money transmission

Card network rules aren’t the only rules that care who holds the money. Holding and moving your customers’ settlement funds can trigger state money transmission licensing. Visa itself warns that local laws in some jurisdictions may require PFs or marketplaces to hold a money transmission license, or something similar, to receive and transmit settlement funds.

Many states have adopted the Money Transmission Modernization Act, the model law from the Conference of State Bank Supervisors (CSBS), in full or in part. The CSBS tracker, updated in April 2026, lists enactments in states including Colorado, Illinois, Massachusetts, Texas, Virginia and Wisconsin.

The model act includes an agent-of-payee exemption, but it is conditional, and not every state has an explicit one. Whether your platform needs a license depends on the states involved and on how your agreements set up the flow of funds, so have counsel review it state by state before you hold or move customers’ funds. This guide is general information, not legal advice.

Onboarding duties and Form 1099-K

Signing merchants means checking who they are, starting with know-your-business (KYB) checks on the company and its owners.

Mastercard’s Security Rules and Procedures, Merchant Edition (August 4, 2026), list the steps for the acquirer and any PF signing a sub-merchant: verify the business and each principal owner, screen sanctions, submit a MATCH Pro inquiry, block names that impersonate other businesses, set fraud-loss controls and assign the MCC that best fits the business. Investigation records are kept at least two years after the agreement ends.

Behind those checks sit two bank rules. The Customer Identification Program (CIP) rule requires a name, date of birth for individuals, address and identification number before an account is opened. The customer due diligence (CDD) rule adds beneficial owners: each person who owns 25% or more of a business, plus one person with significant control over it.

Payment facilitators run KYB, sanctions screening and MATCH checks under network rules and their sponsor’s policies. The CIP and CDD rules themselves apply to banks, which pass similar requirements down by contract.

Form 1099-K

Paying merchants also brings tax reporting. As of October 2026, payment card sales are reported on Form 1099-K with no minimum dollar threshold. For third-party network payments, the threshold is back to more than $20,000 and more than 200 transactions, after the One, Big, Beautiful Bill restored the earlier limit retroactively.

When several parties are involved, the IRS puts the filing duty on the entity that submits the instructions to transfer funds to the payee. A PF that pays its sub-merchants takes on these reporting duties.

The higher-risk view of payment processors

Banks that sponsor payment programs answer to regulators, and regulators have long treated third-party payment processors as higher risk. FinCEN’s advisory FIN-2012-A010 describes processors as bank customers that initiate card, ACH and remotely created check transactions for merchants that have no direct relationship with the bank.

FinCEN tells banks to run initial and ongoing due diligence on processors and their merchants, including whether processors have obtained all necessary state licenses.

The advisory’s red flags include high consumer complaints, high returns or chargebacks, accounts spread across many banks, and unauthorized return rates that look normal in total but are high for individual merchants. Expect a bank behind a payments program to look at your platform and at each of your customers, not only at your totals.

The ACH side

The card models above don’t decide your role for ACH. Bank payments run under the Nacha Rules, which define a Third-Party Service Provider as any party that performs ACH processing functions for another party. The bank that sends entries into the ACH Network for an originator is the Originating Depository Financial Institution (ODFI).

A platform that holds the ODFI agreement and sends entries for its customers is a Third-Party Sender. If its customers hold the bank agreement, it is a Third-Party Service Provider. If it sends through another Third-Party Sender, it is a Nested Third-Party Sender. Which applies depends on whose name is on the bank agreement.

As of October 2026, Third-Party Senders carry these duties of their own under the Nacha Rules.

• An annual Rules Compliance Audit and a risk assessment, with a risk program built on it. Since September 30, 2022, each Third-Party Sender must do its own risk assessment and can’t rely on another party’s assessment or audit.
• Origination agreements, both with the ODFI and with the parties they send for. Nested Third-Party Sender relationships must be disclosed, and ODFIs register their Third-Party Senders with Nacha.
• Data security, which above 2 million entries a year means making stored deposit account numbers unreadable.
• Fraud monitoring, under Nacha rules fully in force since June 2026. Every non-consumer Originator, Third-Party Service Provider and Third-Party Sender must have risk-based processes to detect entries initiated by fraud, including payments obtained under false pretenses, and review them at least once a year.
• Return rate thresholds, the debit return levels Originators and Third-Party Senders are measured against: 0.5% for unauthorized returns, 3.0% for administrative returns and 15.0% overall. The unauthorized threshold carries enforcement exposure, and crossing the administrative or overall level triggers a preliminary inquiry into origination practices.

For more on who the fraud rules cover and what they ask, read what Nacha’s 2026 fraud monitoring rules mean for software platforms.

Questions to answer before you choose

Work through these with your team, your counsel and any provider you talk to.

• Do you want to sign merchants yourself? Signing merchants for an acquirer is an ISO or payment facilitator role.
• Will you ever hold or move your customers’ funds? Receiving settlement is a PF function, and it can raise money transmission questions.
• Who absorbs a loss if a customer disappears? Disputes and losses don’t go away when a merchant closes. Find out whose money covers them.
• Which verticals do you serve? Both networks exempt certain utility, rental, medical, education and tax payment MCCs from the sub-merchant thresholds. Only the listed codes qualify, so check your customers’ exact MCC.
• Will you originate ACH for your customers? Whose name is on the bank agreement decides your Nacha role and its duties.
• What do your contracts say about liability? Network rules keep the acquirer liable; contracts decide how losses pass to a PF and to your platform.
• Has counsel reviewed money transmission? Licensing and the agent-of-payee exemption vary from state to state.

Sources

1. Visa, Visa Core Rules (public edition)
2. Visa, Visa acceptance entities
3. Visa, The Visa payment facilitator model
4. Visa, Third Party Agent Registration Program: TPA types and functional descriptions
5. Mastercard, Mastercard Rules
6. Mastercard, Payment facilitators
7. Mastercard, Security Rules and Procedures, Merchant Edition
8. Conference of State Bank Supervisors, Money Transmission Modernization Act legislative update
9. Legal Information Institute, 31 CFR 1020.220, Customer Identification Program
10. Legal Information Institute, 31 CFR 1010.230, beneficial ownership requirements
11. FinCEN, Risk associated with third-party payment processors (FIN-2012-A010)
12. IRS, Instructions for Form 1099-K
13. IRS, Form 1099-K threshold FAQs
14. Nacha, Third parties in the ACH Network
15. Nacha, Fraud monitoring (Phase 2)