PayFac vs PayFac-as-a-service vs referral: which fits your software

PayFac vs PayFac-as-a-service comes down to whose name is on the card network registration. A payment facilitator (PayFac) is registered through an acquiring bank, signs merchants as its own sponsored merchants, and usually receives their settlement and pays them out. With PayFac-as-a-service, a provider holds that registration in most setups, and your software embeds its onboarding and payments under your brand.

There is a third model most comparisons skip: referral and partner. Your software refers customers to a processor, each one applies for its own merchant account, and the processor runs underwriting, payments and disputes. You build on its API and are paid under a partner agreement, without ever holding a merchant's money.

Three questions decide which fits: who signs the merchant, who touches the money, and who pays when a dispute lands. Flux works with software companies through the third model (how Flux fits).

PayFac vs PayFac-as-a-service vs referral partner at a glance

Vendors use these labels loosely, so compare structures. This is the typical shape; contracts decide the details.

What a payment facilitator is under card network rules

The Visa Core Rules and Visa Product and Service Rules (24 October 2026 edition) define a payment facilitator as an entity that contracts with an acquirer to deposit transactions, receive settlement from, or contract with an acquirer on behalf of a sponsored merchant.

Visa's guide to additional acceptance entities (February 2024) says an entity that signs merchants for an acquirer or receives settlement for sellers "is considered a PF, even if they don't perform both functions." A platform that collects card payments into its own account and pays its customers out is likely doing a PayFac's job (Visa classes some such platforms as marketplaces instead), whatever it calls itself, and holding the money for only a day doesn't change that.

Visa's duties for a PayFac and its acquirer:

• Liability runs uphill. A sponsored merchant is treated as a merchant of the PayFac's acquirer, which is liable for all acts and omissions of the PayFac and its sponsored merchants (5.3.1.2). The PayFac must be financially liable for each transaction it processes for them, and for cardholder disputes (5.3.1.1).
• Registration comes first. The acquirer registers the PayFac, attesting to its due diligence, and Visa must confirm it before transactions flow (5.3.1.3). PayFacs must also be registered as Visa third party agents, with no affiliate exemption (1.9.8.6).
• Every merchant needs an agreement and screening. The PayFac must sign each sponsored merchant, check that it is financially responsible, in an allowed jurisdiction and not engaged in harmful activity (1.5.1.3, 1.5.2).
• Identifiers and MCCs. Each sponsored merchant gets a unique ID and the right merchant category code (MCC), and the acquirer must ensure the PayFac can see any positive matches on the Visa Merchant Screening Service (5.3.1.3).
• Both names on the receipt. The merchant name on the receipt must include the PayFac's name and the sponsored merchant's (5.9.2.2), so your name is in front of the cardholder.

American Express's payment facilitator fact sheet (October 2024) calls the PayFac the merchant of record for its program merchants, so that status depends on the network. For the merchant's view of a pooled account versus its own, see aggregators vs dedicated merchant accounts.

The USD 1 million sponsored merchant rule

Many pages still cite an old $100,000 figure. Visa's current rule (5.3.1.4, last updated October 2025) requires the acquirer to sign a direct merchant agreement with any sponsored merchant above USD 1 million in annual Visa transaction volume: before processing for a merchant new to the PayFac, or within 2 years after an existing one crosses the line.

The merchant does not have to leave: the PayFac may continue to provide payment services, including settlement. No direct agreement is needed if the PayFac has held the relationship for at least 2 years with the same acquirer, reports volume, disputes and fraud to it, and the acquirer keeps overseeing it. Some categories, such as utilities, rentals, healthcare, education and government payments, are exempt too.

The exemptions fall away if the acquirer, PayFac or merchant is identified in a Visa risk program, or had excessive violations in the prior 3 years. The 2-year relationship route is also narrower for high-integrity risk, T&E and advance-payment merchants.

Mastercard's threshold is higher: Rule 7.8 of its June 2026 rules requires a direct acquirer agreement above USD 10 million in combined Mastercard and Maestro annual volume, unless threshold conditions are met or the merchant is in an exempt MCC.

High-risk merchants change the math

A PayFac that signs high-integrity risk merchants must be registered with Visa as a High-Integrity Risk Payment Facilitator. An acquirer that misses the requirements faces USD 25,000 per month per PayFac, and more after repeat violations (12.3.1.1). If your customers sell betting, adult content or other high-risk services, see high-risk payment processing.

What PayFac-as-a-service really means

PayFac-as-a-service (PFaaS) is a vendor category, not a card network term. In most setups the provider is the registered payment facilitator: it signs your customers as its sponsored merchants and settles them.

Some "managed PayFac" offers work the other way: your company becomes the registered PayFac and the vendor runs underwriting, risk and payouts for you. That puts you back in the liability chain above: same label, opposite structure.

Where the provider is the PayFac, it typically runs identity checks and underwriting decisions, risk monitoring, payouts, 1099-K filing and network-facing disputes: a shorter road than registering yourself, depending on the provider. You still own the onboarding screens, first-line support, your brand on checkout and any losses passed back by contract, and the provider has the final word on approvals, reserves and holds.

Revenue usually comes as a share of the provider's processing margin, or as merchant pricing you set above a cost the provider charges you; the card networks set neither. Liability toward the networks moves to the provider and its acquirer, but what you owe the provider when a merchant leaves a loss behind is a matter of contract, and those contracts usually pass some of it back.

Questions to get answered in writing

1. Whose name is on the Visa and Mastercard payment facilitator registration?
2. Who signs the sub-merchant agreement, and is my company a party to it?
3. When a merchant can't cover a chargeback or fraud loss, who pays, and is there a cap?
4. Who holds reserves, and who decides when funds are held? (See rolling, capped and upfront reserves.)
5. Who files Form 1099-K for my merchants?
6. If we leave, can our merchants and their stored payment tokens move with us?

The referral and partner model

Here your software never becomes a payments company. Each customer applies to the processor, is underwritten and, if approved, gets its own merchant account. The processor and its acquiring bank sign the merchant, settle funds to it, handle disputes and file its Form 1099-K. You integrate through its API, hosted card fields and payment links, so payments still happen inside your product.

FinCEN's ruling FIN-2014-R009 (August 2014) shows why that matters: it found that an independent sales organization (ISO) working under a marketing and sponsorship agreement, which never took possession or control of merchant funds, was not a money transmitter for that activity. Rulings apply only to the company that asked and only to federal law, but they show FinCEN's logic: a company that never holds merchant funds leaves the federal money transmission questions with the parties that do.

You earn under the partner agreement; the card networks don't set referral compensation. The trade-offs are less control over approvals and pricing, a customer relationship shared with the processor, and integrations limited to its API. In return you carry less liability and compliance work.

It is not zero responsibility: your partner agreement sets duties of its own, and if your software touches card data, PCI DSS applies to that part of your stack. Hosted card fields keep card numbers off your servers and shrink that scope.

What comes with touching the money

Once you receive settlement and pay merchants, obligations outside the card network rules apply. This is general information, not legal or tax advice: work through your own funds flow with a payments attorney and a CPA.

Money transmission, federal and state

Federal rules exclude from the definition of money transmitter a person that only acts as a payment processor for the purchase of goods or services, or bill payment, through a clearance and settlement system by agreement with the seller or creditor (31 CFR 1010.100(ff)(5)(ii)(B)). FinCEN's 2014 ruling lists four conditions, including operating through clearance and settlement systems that admit only BSA-regulated financial institutions.

States regulate separately. The Conference of State Bank Supervisors says 31 states have enacted the Money Transmission Modernization Act in full or in part (as of September 2026). The model law's agent-of-payee exemption requires a written agreement in which the payee appoints you to collect on its behalf, that the payee hold you out to the public as collecting for it, and that payment to you count as payment to the payee. State recognition of it varies.

Form 1099-K

The IRS Instructions for Form 1099-K (Rev. December 2026) make anyone that receives payments from a payment settlement entity for payees and distributes them the payment settlement entity for those payees. In plain terms, a PayFac that settles its sub-merchants is generally the filer of their 1099-Ks, though the parties can agree in writing to have another party file.

Payment card transactions have no de minimis exception (the $20,000 and 200-transaction threshold restored by the One, Big, Beautiful Bill, P.L. 119-21, covers third party network transactions), and gross amounts are reported before refunds and fees.

ACH and PCI DSS

• ACH. Nacha's Third-Party Sender Roles and Responsibilities rule (effective September 30, 2022) requires every Third-Party Sender, nested ones included, to run its own ACH risk assessment, a duty that cannot be passed to another party. A platform that originates ACH for customers often falls into this category; ask your bank.
• PCI DSS. The current standard is v4.0.1. A PayFac is a Visa third party agent and validates as a service provider. Visa's 2015 service provider guidance sets levels by annual Visa transaction count: Level 1 validates with an annual onsite assessment, Level 2 with an annual SAQ-D. Confirm current levels with your acquirer.

How to choose the model that fits your software

Work through these in order. If the first three point the same way, you likely have your answer.

1. Do you need to own onboarding and pricing? If approving merchants and setting their rates is core to your product, you are choosing between PayFac and PFaaS. If customers just need to get paid inside your product, referral covers it.
2. Will you staff risk, compliance and finance operations? A registered PayFac underwrites every merchant, watches disputes and fraud, files 1099-Ks and validates PCI DSS as a service provider. If you won't hire for that, don't register.
3. What verticals are your customers in? High-integrity risk merchants bring extra registration, penalties and stricter underwriting under any model.
4. How concentrated is your volume? Under Visa's rules, customers above USD 1 million a year in Visa volume will need direct agreements with the acquirer unless an exemption applies.
5. What is your exit plan? Ask who owns the merchant relationships and payment tokens if you switch. Under referral, each merchant already holds its own account.

What each model costs and how long it takes

The card networks publish no timeline for becoming a PayFac, and vendors' cost and time figures are unsourced estimates, so get quotes from acquirers. A registered PayFac budgets for the acquirer's due diligence and Visa registration, PCI DSS service provider validation, underwriting, risk and compliance staff, any reserves or collateral the acquirer requires, legal and money transmission review, and 1099-K operations.

With PFaaS, the cost sits in the contract terms: the revenue share, any minimums and the losses passed back to you. A referral model costs integration work plus a partner agreement, and each merchant still goes through the processor's underwriting, with no set approval time.

A hypothetical worked example

Say a field-service scheduling app has 2,000 small business customers. Most process $50,000 to $400,000 a year in cards, a dozen larger HVAC firms are near $1.5 million each, and the company has two engineers on payments and no risk staff.

• As a registered PayFac, it would carry every cost in the list above, with no risk staff to run it. The dozen larger firms are new to it, so any whose Visa volume alone tops USD 1 million a year would need a direct agreement with the acquirer before processing.
• With PFaaS, it gets a branded onboarding flow sooner, and the work moves into the contract: who absorbs the loss if a merchant disappears after a run of chargebacks.
• As a referral partner, each approved customer gets its own merchant account and the app builds checkout on the processor's API and hosted fields. It gives up control of approvals and pricing, and carries no settlement, no 1099-K filing and no network registration.

With no risk staff, referral or PFaaS fits this company today. If payments becomes a large share of revenue and it builds a risk team, registering is worth revisiting. Several rules above changed in 2025 and 2026, so confirm current ones with your acquirer, attorney and CPA.

How Flux fits

Flux works with software companies through its referral and partner program. It is not a PayFac-as-a-service: your customers are not onboarded under a master account, and your software does not hold their funds.

Each business you refer applies to Flux, a person reviews the application, and approved businesses get their own Flux account. Flux runs the payments, security and support. Your software can build on the Flux payments API, hosted fields and payment links, the way the GoHighLevel integration lets each business connect its own Flux account. Flux is PCI DSS SAQ-D Level 2 certified and SOC 2 Type I compliant, Type II in progress.

Partners use the Flux partner portal to refer merchants and track each one from application to live processing. Partners are paid monthly, with compensation set in the partner agreement. You can talk rates with the merchant, and Flux confirms the final rate upfront. To become a partner, email support@fluxpayments.com; for anything more specific, talk to the team.