What Is a Payment Facilitator (PayFac)? Founder Primer

A payment facilitator (PayFac) is a company that lets other businesses accept card payments without those businesses opening their own merchant account. The PayFac holds one master merchant account with an acquiring bank and a card network, then onboards each customer as a "sub-merchant" underneath it. In exchange for taking on the onboarding, underwriting, and compliance work, the PayFac earns a share of every transaction its sub-merchants process.

Quick answer

If you're deciding whether your startup needs to become a payment facilitator, the short version is: most software companies don't need to, at least not at first. You can plug in a payments provider that already runs a PayFac program — Stripe and Square are the two most commonly cited examples of this model — and get sub-merchant onboarding without building a compliance function. Becoming a PayFac yourself only starts to make sense once payments are core to your product and you want direct control over onboarding speed, risk rules, and the economics of every transaction. That's a build-versus-buy decision, not a payments-feature decision, and it deserves the same validation rigor as any other core-infrastructure bet.

How the PayFac model works

To understand a payment facilitator, it helps to start with what came before it. Traditionally, any business that wanted to accept card payments had to apply for its own merchant account directly with an acquiring bank. That application went through full underwriting — credit checks, business verification, risk review — and could take days or weeks. Every business needed its own account, its own underwriting file, and its own relationship with the bank.

The PayFac model collapses that process. Instead of each sub-merchant opening an individual account, the payment facilitator opens a single master merchant account and takes on the legal responsibility for everything that happens under it. The card networks and the acquiring bank see one entity: the PayFac. The PayFac, in turn, is responsible for knowing who its sub-merchants are, verifying they're legitimate businesses, monitoring their transactions for fraud, and absorbing a meaningful share of the liability if something goes wrong.

Three roles sit inside this structure, and it's worth keeping them distinct:

• The acquiring bank provides the underlying banking relationship and ultimately bears the deepest liability in the chain. It underwrites the PayFac itself, not each sub-merchant individually.
• The payment facilitator is the intermediary. It builds (or licenses) the technology to onboard sub-merchants, runs its own underwriting and risk checks, moves funds, and answers to the acquiring bank and card networks for the sub-merchants' behavior.
• The sub-merchant is the end business — a seller, a service provider, a marketplace vendor — that gets to start accepting payments quickly because the PayFac has already done the heavy lifting of establishing the master account.

The trade a PayFac makes is speed for responsibility. Sub-merchants can be onboarded in minutes instead of weeks because the PayFac applies its own, often automated, underwriting rules rather than sending every applicant through a bank's manual review. That speed is valuable, but it isn't free: the PayFac now owns the underwriting decision, owns the fraud and chargeback exposure that comes with getting that decision wrong, and owns the compliance obligations — anti-money-laundering checks, know-your-customer verification, ongoing transaction monitoring — that a bank would otherwise have carried directly.

This is also why becoming a PayFac isn't a weekend integration. A company that wants to run its own PayFac program typically has to be sponsored by an acquiring bank and approved by the relevant card networks, build or buy underwriting and risk infrastructure, and stand up ongoing compliance operations. Most companies never do this directly. Instead, they use a payments provider that has already built the PayFac infrastructure and exposes it as a feature — commonly marketed as "PayFac-as-a-service" or embedded payments.

Concrete example: a SaaS platform embedding payments as a PayFac

Picture a SaaS company that sells booking and invoicing software to independent contractors — plumbers, electricians, personal trainers. Before adding payments, the product's job ends at generating an invoice; the contractor still has to go set up their own separate merchant account somewhere else if they want to accept a card on the spot.

Now the SaaS company adds embedded payments using a PayFac-as-a-service provider. Here's what changes: when a contractor signs up, they fill out a short onboarding form inside the SaaS product itself — no separate application to a bank, no waiting on a merchant services rep. Behind the scenes, the SaaS company (acting as a PayFac, via its payments provider's infrastructure) runs automated underwriting: verifying the business's identity, checking it against fraud and sanctions lists, and deciding whether to approve, decline, or flag the account for manual review. Once approved, the contractor is live as a sub-merchant under the SaaS company's master merchant account and can start taking card payments the same day.

The SaaS company now earns a small percentage of every transaction its contractors process — a new revenue line that didn't exist when it was just selling software licenses. But it has also taken on new obligations: it's the one who has to catch a contractor who's actually running a different, higher-risk business than they claimed; it's the one who eats a share of the loss if a sub-merchant's customer disputes a charge and the sub-merchant can't cover it; and it's the one who has to keep records and monitoring in place well enough to satisfy the acquiring bank's periodic audits. In practice, most companies at this stage don't build the underwriting and compliance engine themselves — they license it from a payments provider that already runs PayFac infrastructure and rent the capability, while still carrying the sub-merchant relationship and much of the risk exposure that comes with it.

PayFac vs. ISO vs. aggregator vs. PayFac-as-a-service

These four terms get used loosely and interchangeably, which causes real confusion when you're trying to figure out what you're actually building or buying. Here's how they differ:

The distinction that trips founders up most often is aggregator versus PayFac. Both pool many businesses under one account, and from a user's perspective the onboarding experience can look similar. The meaningful difference is in how rigorously each sub-merchant or transacting entity is identified, underwritten, and monitored, and how much liability the intermediary formally carries for that entity's behavior — a PayFac is expected to know and vouch for each sub-merchant individually, while a pure aggregator model has historically been used for looser, lower-risk pooling. Card network rules on this have tightened over time, which is part of why PayFac-as-a-service has become the more common path for new platforms rather than running an informal aggregator model.

When becoming a PayFac matters for validating your idea

If you're validating a startup idea that touches payments, the PayFac question isn't "do we need it" in the abstract — it's "does owning the sub-merchant relationship and the underwriting decision change what we're actually testing." A few situations where it matters:

Payments is the product, not a feature bolted onto the product. If your core value proposition is faster or cheaper access to payment acceptance — not software that happens to also move money — then the underwriting speed and revenue share that come with a PayFac-level relationship may be central to whether the idea works at all. Validate that assumption directly rather than assuming a generic payments integration will do.

Your unit economics depend on the payments take rate. A percentage of transaction volume can be a real revenue line, but it only shows up if you're positioned to earn it — which usually means acting as a PayFac (directly or via PayFac-as-a-service) rather than simply redirecting users to a third-party checkout. If your business plan leans on payments revenue, pressure-test whether the model you're planning to use actually captures that revenue before you build around the assumption.

Onboarding friction is the thing you're trying to fix. If your wedge is "sign up and start accepting payments today" for a segment that currently waits days or weeks for a merchant account, that's a PayFac-shaped problem by definition, and it's worth confirming a PayFac-as-a-service provider can actually deliver that speed for your specific customer segment and risk profile before you promise it.

You're not sure yet, and payments is incidental. If your product's value is somewhere else entirely — scheduling, inventory, communication — and payments is a convenience you're adding later, don't front-load a PayFac decision. Use a standard payments integration, validate the core product first, and revisit the PayFac question once payments volume and revenue are large enough to justify the added underwriting and compliance responsibility.

The general pattern worth internalizing: the PayFac model shifts risk and complexity toward whoever holds the master account, in exchange for speed and revenue. That's a trade, not a free upgrade. Deciding whether to make that trade is exactly the kind of assumption that belongs in early validation, not in a technical spec written after you've already committed to a payments provider. For a broader framework on validating a payments-specific idea end to end, see how to validate a payments startup idea; and if you're still mapping who else already occupies this space, mapping the payments competitor landscape is a useful companion piece.

Key takeaways

• A payment facilitator (PayFac) holds one master merchant account and onboards other businesses as sub-merchants underneath it, taking on their underwriting, risk, and compliance responsibility in exchange for a share of transaction revenue.
• The trade a PayFac makes is speed for responsibility: sub-merchants get near-instant onboarding, and the PayFac absorbs the liability and compliance burden that a bank would otherwise carry.
• Most startups don't need to become a licensed PayFac directly — PayFac-as-a-service providers let you offer PayFac-speed onboarding while renting the underwriting and compliance infrastructure.
• PayFac, ISO, and aggregator are not interchangeable: they differ in who holds the merchant account, who owns underwriting, and how individually each transacting entity is identified to the card network.
• Whether the PayFac question matters for your idea depends on whether payments is your core product, a real revenue line, or an incidental feature — validate that positioning before committing to a payments architecture.

FAQ

Is Stripe a payment facilitator? Stripe operates a PayFac program and also offers PayFac-as-a-service infrastructure that other platforms use to run their own sub-merchant programs. Which role applies to you depends on which product you integrate and how the sub-merchant relationship is structured — check the specific offering rather than assuming.

Do I need to become a licensed PayFac to accept payments in my app? No. Most software companies integrate a payments provider's standard checkout or billing product and never touch PayFac status directly. Becoming a PayFac (or using PayFac-as-a-service) only becomes relevant if you want to onboard other businesses as sub-merchants under your own umbrella.

What's the difference between a PayFac and a payment gateway? A payment gateway is the technical pipe that transmits transaction data to the card networks and banks for authorization; it doesn't take on underwriting or merchant-account responsibility. A PayFac is a business and compliance role — it decides who gets to transact and carries liability for that decision. Many payments providers offer both a gateway and a PayFac program, but the two are functionally different things.

How long does it take to become a payment facilitator? Becoming a licensed PayFac directly — with your own acquiring bank sponsorship and card network approval — is a multi-month process involving compliance, risk, and technical review, and it's a commitment most early-stage companies aren't ready to make. Using a PayFac-as-a-service provider is much faster, often weeks, since you're building on infrastructure that's already been approved.