What Is a Payment Facilitator (PayFac)? Complete 2026 Guide

Quick answer: A payment facilitator, or payfac, is a company that holds a single master merchant account with an acquiring bank and onboards other businesses underneath it as sub-merchants. Instead of each business waiting weeks for its own merchant account, the payfac approves them in minutes and takes on underwriting, risk, and compliance responsibility for them. Stripe, Square, and PayPal are the best-known examples. The critical limitation: a payfac solves payment acceptance, not tax liability. Sub-merchants normally remain responsible for their own sales tax and VAT.

The payfac model is why you can sign up for Stripe on a Tuesday afternoon and take a card payment before dinner. Before it existed, accepting cards meant applying directly to an acquiring bank, submitting financials, and waiting weeks for underwriting.

This guide covers what a payment facilitator actually is, how the model works mechanically, what it costs to become one, and the responsibilities it does and doesn't transfer. If you're specifically comparing models, we also have dedicated guides to PayFac vs. ISO and PayFac vs. payment processor.

What is a payment facilitator?

A payment facilitator is a registered entity that enables other businesses to accept card payments under its own merchant account, rather than each business obtaining one directly from an acquiring bank.

The payfac signs an agreement with an acquirer, gets registered with the card networks (Visa, Mastercard, and others), and then onboards businesses as sub-merchants beneath its master account. To the card networks, the payfac is the merchant. To the sub-merchant, the payfac is the provider that makes payments possible.

The term is used interchangeably with "payment aggregator," which is the older name for the same structure. Visa and Mastercard formalized the model in the early 2010s, which is what allowed it to scale beyond a handful of players.

How the payfac model works

The mechanics come down to one structural choice: who holds the merchant account.

In the traditional model, each business applies to an acquiring bank, goes through underwriting, and receives its own merchant identification number (MID). It's thorough, slow, and expensive to administer, which made it a poor fit for small businesses and impossible for platforms wanting to onboard thousands of sellers.

In the payfac model, the payfac holds one master merchant account and issues sub-merchant IDs underneath it. Onboarding becomes a form rather than an application. The payfac runs its own KYC and risk checks, approves or declines in near real time, and starts processing.

The trade-off is that the payfac inherits the risk it just removed from the bank. If a sub-merchant commits fraud or fails to deliver goods and can't cover the chargebacks, the payfac is on the hook. That's why payfacs invest heavily in underwriting automation, transaction monitoring, and reserves.

What a payment facilitator is responsible for

A registered payfac takes on a substantial operational load:

• Sub-merchant underwriting and KYC. Verifying identity, business legitimacy, and beneficial ownership before approval.
• Onboarding and provisioning. Issuing sub-merchant IDs and configuring processing.
• Transaction monitoring. Watching for fraud, money laundering, and prohibited activity on an ongoing basis.
• Chargeback and dispute management. Handling the dispute process and absorbing losses that sub-merchants can't cover.
• PCI DSS compliance. Maintaining Level 1 compliance for the platform and helping sub-merchants meet their obligations.
• Funds settlement. Receiving settlement from the acquirer and distributing payouts to sub-merchants.
• Card network reporting. Meeting registration, reporting, and volume-threshold requirements set by Visa and Mastercard.
• Regulatory compliance. AML programs, sanctions screening, and money-transmission considerations depending on jurisdiction.

What a payment facilitator does not cover

This is the part that catches businesses out, and it's worth stating plainly.

A payfac does not handle your sales tax or VAT. The payfac is facilitating payment acceptance. It is not the legal seller of your product. That means calculating, collecting, filing, and remitting consumption taxes in every jurisdiction where you have obligations remains your responsibility as the sub-merchant.

This is why businesses on Stripe or Square typically buy separate tax software, and why Stripe sells Stripe Tax as a distinct product. The payment side being solved does not mean the tax side is.

The same applies to a few other liabilities that stay with you:

• Product liability and warranty obligations
• Consumer-protection compliance in the markets you sell into
• Ultimate responsibility for your own PCI scope, depending on integration
• Refund policy and its funding

If you want those transferred as well, that's the merchant of record model rather than the payfac model. We cover the distinction in detail in Merchant of Record vs. Payment Facilitator.

Becoming a payfac vs. PayFac-as-a-Service

If you run a software platform and want to monetize payments, there are two routes.

Full payment facilitation

You register with the card networks, secure an acquiring relationship, build or buy underwriting and risk systems, achieve PCI Level 1 compliance, and staff compliance and support functions.

The economics can be excellent, since you capture a spread on every transaction across your whole customer base. The costs are also real: registration fees, meaningful upfront engineering, ongoing compliance overhead, and genuine financial exposure to sub-merchant losses. Most estimates put the realistic entry point in the high six figures to low seven figures of first-year investment, plus 12 to 18 months of build time.

It makes sense at scale. Below roughly $50 million to $100 million in annual processing volume, the fixed costs are usually hard to justify.

PayFac-as-a-Service (managed payfac)

The middle path, and the one most platforms actually take. A provider supplies the payfac infrastructure, registration, and compliance, while you get the branded payments experience and a share of the economics.

You give up some margin compared with full facilitation, and you inherit the provider's risk appetite and policies. In exchange you launch in weeks rather than a year, without becoming a regulated payments company. "PayFac-as-a-service" and "managed payfac" describe the same arrangement.

The economics of the payfac model

The payfac makes money on the spread between what it pays the acquirer and card networks (interchange plus assessments plus acquirer markup) and what it charges sub-merchants.

The familiar 2.9% + 30¢ pricing is a blended rate designed to be simple and predictable. Actual interchange varies considerably by card type, region, and transaction characteristics, so the payfac absorbs that variability and profits on the average.

For a software platform, the appeal is that payments revenue attaches to volume the platform already handles. For the sub-merchant, the appeal is speed and simplicity, at a rate typically higher than a negotiated direct merchant account would deliver at scale.

Who should use or become a payfac?

Using a payfac as a merchant makes sense when you:

• Want to start accepting payments immediately, without underwriting delays
• Are small, early-stage, or process modest volume
• Sell primarily in one market with manageable tax obligations
• Can handle your own tax compliance, or are happy to buy tooling for it

Becoming a payfac makes sense when you:

• Run a vertical software platform serving many merchants who need payments
• Process (or credibly will process) volume large enough to justify fixed costs
• Have appetite for regulatory and risk responsibility, or will use a managed provider
• See payments as a strategic revenue line rather than a feature

Neither fits well when you:

• Sell digital products or SaaS internationally, where VAT and GST obligations arrive with the first foreign sale
• Want tax, chargeback, and compliance liability off your books entirely
• Would rather not maintain a tax engine alongside your payment stack

That last case is the merchant of record model, where a provider becomes the legal seller and takes on the tax and liability the payfac model leaves behind. For software and digital sellers going global, it's usually the more complete answer. (See what a merchant of record is.)

Payfac vs. other payment models at a glance

Model	Holds merchant account	Onboarding speed	Handles your sales tax / VAT	You are the legal seller
Payment facilitator (payfac)	Payfac (master account)	Minutes	No	Yes
ISO	You (own MID)	Days to weeks	No	Yes
Payment processor	You	Days to weeks	No	Yes
Payment gateway	Not applicable	Immediate	No	Yes
Merchant of record (MoR)	The MoR	Days	Yes	No, the MoR is

The pattern worth noticing: every model except the merchant of record leaves you as the legal seller, which means the tax obligations stay with you no matter how the payment plumbing is arranged.

The bottom line

The payfac model solved a real problem: it made card acceptance instant for millions of businesses that would never have made it through traditional underwriting. If you want to start taking payments quickly, or you're a platform looking to monetize payments across your customer base, it's a proven structure.

Just be precise about what it transfers. A payfac takes on underwriting, risk, and payment compliance. It does not take on your tax obligations, your product liability, or your status as the legal seller. Those stay with you in every market you sell into.

If you sell software or digital products internationally and want those obligations genuinely off your books, talk to the team at Comecero. We're a merchant of record for SaaS, AI, and high-ticket digital sellers, covering payments, global tax remittance, chargebacks, and compliance in one relationship.