ISV vs PayFac for Vertical SaaS: The Real Comparison

ISV vs PayFac is the question every vertical SaaS platform eventually faces. Usually right around the moment payments revenue starts looking like a real line item, the founder or VP of product asks finance what would happen if they captured more of the spread. This is payment facilitation vs the referral model, the choice between staying an ISV that refers merchants for a residual or becoming a PayFac that facilitates the payments and owns the spread. PayFac vs ISV is the choice between those two structural options, and most platforms get the comparison wrong on the first pass.

The short version: ISV is the entry point, PayFac is the destination, and the migration between them is rarely as smooth as the slide deck makes it sound. The right model for a specific platform depends on volume, vertical, operational appetite and where the platform is in its lifecycle. None of those answers is universal, and the wrong answer at the wrong time can cost a platform six figures of annual margin or trap it in an operational program it was not ready to run.

An ISV refers its customers to a processor and earns a residual (5 to 15 bps) while the processor owns the merchant and the operational burden. A PayFac boards its own sub-merchants, sets pricing and captures the full spread (50 to 120 bps) in exchange for taking on risk, disputes and compliance. ISV is the entry point, PayFac the destination.

What does ISV actually mean in payments?

An ISV in payments is an Independent Software Vendor that refers its customers to a payment processor and earns a residual on the volume those customers go on to process. The platform sells software. The processor signs the merchant agreement, runs the underwriting, owns the relationship, runs the operational machine and shares a slice of the economics with the platform that delivered the customer.

Sometimes the industry calls this the ISO model (Independent Sales Organization). The terms are closely related and often used interchangeably. We have a separate piece on PayFac vs ISO that walks through the ISO and ISV terminology distinction in more depth. For purposes of the PayFac vs ISV comparison, treat them as the same model with different labels. The same decision also shows up framed as payment facilitation versus the referral model, which is the same question in different words: keep referring merchants for a residual, or facilitate the payments yourself and own the spread.

The ISV path is the entry point because the bar to start is low. A platform with no payments program can sign an ISV agreement with a processor in days, integrate with a vendor SDK in weeks, and start earning residuals on the first transaction. No PCI program, no sub-merchant onboarding, no underwriting risk, no 24/7 payments operations. The processor owns all of that.

What does PayFac actually mean?

For the full definition, see what a payment facilitator actually is. In short, a Payment Facilitator is a platform that has signed a master merchant agreement with a processor and is operating its own sub-merchant program. The platform underwrites and boards the sub-merchants under its own scope, sets pricing for those sub-merchants, handles settlement and reconciliation, manages disputes and chargebacks, runs a Level 1 PCI compliance program and takes on operational and capital responsibility for the sub-merchant base.

In exchange, the platform captures the spread between what the processor charges it (the cost of processing) and what it charges its sub-merchants. That spread can be 50 to 120 basis points of volume depending on the variant, the negotiation and the vertical. Compared to the 5 to 15 basis points an ISV captures, the PayFac economics are dramatically better. The operational burden is also dramatically larger.

Most platforms that "become a PayFac" today do not actually build the full operational program themselves. They use a managed PayFac partner: Stripe Connect, Adyen for Platforms, Tilled, Finix, Payrix and a handful of others. The managed PayFac partner handles the sub-merchant infrastructure, the PCI program, the settlement and the ops, and the platform captures most of the economics while skipping most of the build, and what that build actually costs is most of the reason almost nobody does it themselves. PayFac-as-a-Service is the sweet spot for the majority of vertical SaaS platforms above a certain volume threshold.

How do the ISV and PayFac economics compare?

The basis-point comparison is the headline number, but the way to compare PayFac vs ISV honestly is to look at annual dollar capture at a representative volume. Here is what each model generates on 25 million dollars of annual processed volume.

Model	Bps captured	Annual margin on $25M	Operational burden
ISV Referral	5 to 15	$12,500 to $37,500	Minimal
ISV with Enhanced Residuals	20 to 40	$50,000 to $100,000	Minimal
Managed PayFac (PFaaS)	50 to 80	$125,000 to $200,000	Moderate
Full PayFac	80 to 120	$200,000 to $300,000	Heavy

The gap between an ISV Referral arrangement and a Managed PayFac at 25 million dollars of volume is roughly 150 thousand dollars per year. At 100 million, it is closer to 600 thousand. At 500 million, the gap is in the millions. The economics tell you why every vertical SaaS platform eventually asks the PayFac vs ISV question, and why the answer for most platforms above a volume threshold is some flavor of PayFac.

How does the operational burden compare between ISV and PayFac?

The economics are only half the comparison. The other half is what each model demands operationally, and this is where most platforms underestimate the trade.

Component	ISV	PayFac (managed or full)
Sub-merchant onboarding	Processor owns it	Platform owns it (managed PFac partner handles plumbing)
PCI compliance program	Out of scope	Level 1, $200K to $500K per year run-rate (full) or managed partner's scope
Sub-merchant pricing decisions	Processor sets prices	Platform sets prices
Disputes and chargebacks	Processor handles	Platform handles or shares with managed partner
Settlement and reconciliation	Processor handles	Platform must build or use managed partner's tooling
Risk and underwriting	Processor owns	Platform shares risk (managed) or owns it (full)
24/7 ops coverage	Processor's pager	Platform's pager (with managed partner backstop)
Capital requirements	None	Modest (managed) to significant (full sponsorship)

This is what the side-by-side comparison really shows. ISV is small economics with small burden. PayFac is large economics with moderate-to-large burden. The decision is whether the additional economics pay back the additional burden at the platform's specific volume and stage.

At what volume does the ISV vs PayFac answer flip?

The general thresholds we see in the vertical SaaS market right now:

• Under $5M annual processed volume. Stay ISV. PayFac economics do not pay back the operational complexity. Focus on activation and attach rate; the bigger lever is more merchants paying through your platform, not better margin per dollar.
• $5M to $25M. The grey zone. ISV with enhanced residuals is often the right answer here. Negotiate the residual share aggressively. Managed PayFac starts to look interesting around the higher end of this range, especially if the platform has product-led activation that pushes volume higher.
• $25M to $100M. Managed PayFac (PayFac-as-a-Service) is usually the right answer. The economics are meaningful enough to justify the build, the operational lift is manageable because the partner handles the heavy work, and the platform captures a real share of the spread.
• $100M to $500M. Managed PayFac still wins for most platforms. The basis points the PFaaS partner keeps are real money, but the operational cost of running a full PayFac at this scale almost always outweighs the basis points captured.
• Over $500M. Full PayFac starts to make sense for platforms that have the engineering depth, the capital and a strategic case for owning the stack. Even at this scale, most platforms stay on managed PayFac. The migration to full PayFac is a multi-year program, not a quarterly initiative.

These thresholds are not bright lines. Vertical matters. Average transaction size matters. Merchant count and concentration matter. A vertical SaaS platform with 200 large merchants doing 5 million each has a different PayFac vs ISV math than a platform with 20,000 small merchants doing 50 thousand each.

What determines the right answer for a specific platform?

The honest diagnostic comes down to four questions.

1. What is the actual annual volume and trajectory?

Not what the platform might do in three years, but what it is doing now and what it will realistically do in twelve months. PayFac economics only pay back if the volume is real and growing. A platform building toward 100 million in volume is a different conversation from a platform that has been at 5 million for three years.

2. Is the merchant base concentrated or fragmented?

Concentrated bases (fewer, larger merchants) are easier to onboard, easier to support, easier to negotiate processor terms for. Fragmented bases (many small merchants) require more operational scale and make PayFac onboarding harder. The merchant base shape matters more than most platforms acknowledge.

3. Does the platform have the operational appetite?

PayFac brings dispute volume, settlement complexity, sub-merchant support questions and the occasional 3am incident. Managed PayFac dampens the burden but does not eliminate it. Some platforms thrive in this operational environment; others find that the payments operational load slowly degrades the rest of the product. Knowing the answer honestly matters.

4. What is the strategic argument for owning the relationship?

For some platforms, owning the merchant-of-record relationship is itself a strategic moat. For others, it is just a way to capture margin. The strategic answer changes how the platform should think about the model. A platform whose entire competitive position depends on payments depth thinks differently from a platform where payments is one of several revenue streams.

What does migrating from ISV to PayFac actually involve?

Most platforms that end up on PayFac started as ISVs. The migration is not painless. Sub-merchants have to be re-boarded under the platform's master agreement. The settlement and reconciliation flow has to be rebuilt. The platform takes on PCI scope it did not have before. Some merchants get lost in the transition. Reasonable expectations: 3 to 6 months of operational distraction, 5 to 15 percent of active merchants lost in re-boarding, and meaningful engineering time pulled off the core product.

The platforms that handle the migration well plan for it from the start. They choose their initial ISV partner with a clear PayFac path in mind. They negotiate ISV agreements that do not penalize migration. They get the data structure right early so that the eventual PayFac sub-merchant import is not a from-scratch rebuild. The platforms that handle the migration poorly are the ones that built ISV for the short term and got stuck when the volume justified PayFac but the operational debt would not allow it.

How should you decide for your own platform?

One mistake worth naming first: most platforms treat this as a permanent choice rather than a stage-appropriate one. ISV and PayFac are two of the main ways SaaS companies make money from payments, and the residuals start to feel meaningful, so platforms stop checking whether they have crossed the threshold where moving up the ladder pays. Re-run the math every year. At 200 merchants processing $150,000 each, $30M in volume earns about $60K a year as an ISV referral and about $270K as a managed PayFac, a $210K gap that widens with every merchant you add. The right model is the one that fits where you are now, but you should be actively managing toward where the economics get meaningfully better, especially if an exit is anywhere on the horizon, payments economics are a standard diligence item in vertical SaaS deals now.

The Margin Multiplier walks through the four-model comparison at your specific volume and vertical in about 60 seconds. It is the right starting point for a platform asking the PayFac vs ISV question for the first time. The output shows what each model would generate, what the recommended move is and what the annual revenue delta of moving up the ladder looks like.

For the deeper decision (which model fits the platform's specific stage, what the right migration path looks like, how to evaluate the managed PayFac partners), the Strategic Decision Framework covers the comparison in detail, including real-world basis-point ranges, the operational requirements at each model and the decision matrix by volume tier.

If the underlying question is really whether to make the jump at all, we cover that head-on in should you become a payment facilitator. And if the platform is at the point of choosing between specific PayFac partners or negotiating an ISV agreement with PayFac migration in mind, that is the kind of situation a Quick Start Call exists for.

Platforms further along, already running multiple processors or expanding into new payment methods, are usually asking a different question: whether to bring in payment orchestration to manage that complexity, not which single model to pick.

Frequently Asked Questions