PayFac vs. ISV: Where Software Platforms Fit in Payments

Quick answer: These describe different things, which is why the comparison confuses people. An ISV (Independent Software Vendor) is a company that makes software, defined by what it sells rather than how it handles payments. A payfac is a payment model. So "PayFac vs. ISV" is really asking: should a software vendor stay a plain ISV that refers payments out, or become a payment facilitator that owns the payment flow and its economics? The answer depends almost entirely on processing volume, with the crossover typically somewhere between $50 million and $100 million annually.

If you build vertical software and your customers accept payments through it, you're sitting on a revenue line you may not be capturing. The industry vocabulary around this decision is genuinely muddled, with "ISV," "payfac," "embedded payments," and "payment monetization" used loosely and sometimes interchangeably.

This guide untangles it: what each term actually means, the three models available to a software vendor, what each one earns, and how to decide. For the underlying payment model, see our guide to what a payment facilitator is.

What is an ISV?

An Independent Software Vendor is any company that develops and sells software rather than hardware or services. A restaurant point-of-sale product, a dental practice management system, a gym booking platform, a field service scheduling tool: all ISVs.

The term is most often used for vertical software, meaning products built for one industry rather than general business use. That vertical focus is precisely what makes payments interesting, because the software already sits at the moment money changes hands. The salon platform knows when the appointment happened. The clinic system knows what was billed. Payment is the natural next step in a workflow the software already owns.

Being an ISV says nothing about payments on its own. It describes what you sell. The payment question is what you do about the transactions flowing through your product.

The three models available to a software vendor

1. Referral (the plain ISV model)

You partner with a processor and refer customers to it. They sign up separately, the processor owns the merchant relationship, and you receive a referral fee or small residual.

• Effort: minimal, often just a link and a logo
• Revenue: smallest share, typically a few basis points
• Control: none, since the processor owns onboarding, support, and pricing
• Customer experience: disjointed, because customers leave your product to set up payments

This is where most ISVs start, and plenty stay here reasonably. If payments are incidental to your product, the effort of anything more may not be worth it.

2. Revenue share / referral plus (managed integration)

You integrate a processor's payments into your product, keep the experience inside your software, and share revenue on the volume you generate. The processor still holds the merchant relationships and carries the risk.

• Effort: moderate integration work
• Revenue: meaningfully better than referral, though well short of full facilitation
• Control: partial, since you shape the experience but not the pricing or risk policy
• Customer experience: good, with onboarding inside your product

3. Payment facilitation (becoming a payfac)

You become the payment facilitator, holding the master merchant account and onboarding your customers as sub-merchants. You set customer-facing pricing, own the relationship, and keep the spread between what you pay and what you charge.

• Effort: substantial, whether through full registration or a managed provider
• Revenue: largest by a wide margin
• Control: complete over pricing and experience, constrained by your provider if managed
• Customer experience: best, with instant onboarding inside your product
• Liability: real, including sub-merchant risk, compliance obligations, and support burden

Most vendors reaching this stage choose PayFac-as-a-Service rather than full registration, which delivers most of the economics in weeks instead of the 12 to 18 months and seven-figure investment that registering yourself requires.

ISV models compared

Dimension	Referral	Revenue share	Payment facilitation
Who owns the merchant relationship	Processor	Processor	You
Onboarding experience	Leaves your product	Inside your product	Inside your product, instant
Revenue per transaction	Lowest	Moderate	Highest
Pricing control	None	Limited	Full
Sub-merchant risk	Processor's	Processor's	Yours or shared
Compliance burden	None	Minimal	Significant
Setup effort	Days	Weeks	Months, or weeks if managed
Best at	Any volume	Low to mid volume	Mid to high volume

The economics: when does becoming a payfac pay off?

The honest answer is that it's a volume question, and the marketing around embedded payments tends to skip that.

At referral level, you might earn a handful of basis points on processing volume. As a payfac, you keep the spread between your cost and your customer-facing rate, which can be an order of magnitude more per transaction.

Against that, payment facilitation carries real costs even in managed form: integration engineering, payments support staffing, some share of chargeback and fraud losses, and ongoing operational attention. Full registration adds compliance staffing, risk reserves, and PCI Level 1 audits.

The rough thresholds most platforms find:

• Under roughly $10 million in annual processing volume, referral or revenue share usually makes more sense. The absolute dollars from facilitation rarely justify the operational load.
• Between $10 million and $50 million, managed payfac starts to make sense, especially if payments are strategically central to the product rather than a bolt-on.
• Above $50 million to $100 million, full registration becomes worth evaluating, since the margin shared with a managed provider starts to exceed what running the infrastructure would cost.

Run the calculation on your own numbers rather than the thresholds. Multiply your annual processing volume by the realistic basis-point gain, then subtract engineering, support headcount, and expected loss rates. Many platforms discover the answer is smaller than the pitch suggested.

What ISVs consistently underestimate

Three costs surface after launch rather than during evaluation:

Support volume. Once payments are in your product, your customers contact you about delayed payouts, declined transactions, and chargebacks. Payment support is specialized, emotionally charged because it involves people's money, and it does not resemble software support.

Underwriting decisions. Even on a managed provider's policy, you decide who to onboard. Approve too loosely and you absorb losses. Approve too tightly and your sales team complains. Someone has to own that trade-off.

Risk concentration. Vertical platforms serve one industry by definition, so if that industry hits trouble, chargebacks arrive across your whole merchant base simultaneously. Diversified payfacs spread that risk. You cannot.

None of these makes payment facilitation a bad idea. They make it a real operational commitment rather than a revenue switch you flip.

The other question ISVs face: selling your own software internationally

Worth separating clearly, because it uses similar vocabulary and gets conflated constantly.

Everything above concerns payments your customers accept from their customers. A different question is how you collect your own software revenue, especially if you sell internationally.

That's not a payfac question at all. Selling SaaS across borders creates VAT, GST, and sales tax obligations that arrive with your first foreign sale, and no payment facilitation arrangement touches them, because the payfac model never changes who the legal seller is. (See Merchant of Record vs. Payment Facilitator for why.)

The model built for that is the merchant of record, where a provider becomes the legal seller and takes on tax remittance, chargeback liability, and compliance together.

A vertical software company selling globally may genuinely need both: payfac infrastructure to monetize customer payments, and an MoR for its own subscription revenue. They're separate decisions with separate vendors, and running them as one procurement is how platforms end up solving neither properly.

The bottom line

PayFac vs. ISV is a category confusion once you look at it directly. The real decision facing a software vendor is how far up the payments value chain to move: refer it out, share revenue on an integrated experience, or become the facilitator and keep the spread.

Volume decides it, and the operational commitment is larger than the revenue pitch suggests. Support, underwriting, and concentrated vertical risk all arrive with the margin.

And if the question you're actually wrestling with is your own international software revenue rather than your customers' payments, that's a different problem with a different answer. Talk to the team at Comecero if so. We act as merchant of record for SaaS, AI, and high-ticket digital sellers, covering global tax remittance, chargebacks, and compliance in one relationship.