Est.

ISV Economics of Embedding Payments vs. Referring Payments

Embedding payments captures 5-10x more revenue than referral from identical transaction volume.

· 9 min read
Cover illustration for “ISV Economics of Embedding Payments vs. Referring Payments”
Embedded Payments Strategy · October 27, 2026 · 9 min read · 1,918 words

Referring and embedding payments differ in both their economic models and their product integrations. For an independent software vendor, the choice determines how much payment volume becomes revenue, what it costs to earn that revenue, and how investors value the business. Embedding usually offers better economics, but how deep to go depends on whether contribution margin at realistic adoption levels can pay for the work it takes to run it.

Why the referral model was a reasonable starting point and why that logic no longer holds

Referral gave ISVs a practical way to support payments without building a payments business. The processor took responsibility for underwriting, merchant-of-record risk, and compliance, while the ISV earned a residual. That division protected a busy software team’s focus. Payroc’s 2026 analysis notes that ISVs often choose their first payments structure while rushing to build a product, without modeling how it will pay off over time. The resulting agreement can then constrain how far the payments program grows.

That starting logic assumed payments were someone else’s core product. Vertical SaaS has weakened that assumption by becoming the merchant’s daily operating environment, where software and transactions increasingly belong to the same workflow. Payments are no longer a peripheral service. Yet a referral arrangement still allocates much of their economic value and control to an external provider. ISVs therefore now need to consider both whether to embed payments and what staying in referral actually costs.

The four models on the table and what each one actually means for who owns what

The four models divide ownership of merchant relationships, pricing, and risk differently. Referral / ISO is the lightest arrangement for the ISV. It refers merchants to a processor, earns a small residual, holds no merchant accounts, and performs no underwriting. The processor owns the payments relationship, so the platform’s role in the transaction is commercially limited even when its software generates the referral.

Integrated / fee-on-top markup gives the ISV a more direct revenue mechanism. The platform sets a price above processing cost and retains the spread, but the provider still controls the underlying pricing flexibility, data access, and merchant experience. An API connection does not transfer those rights. Coinflow’s 2026 explainer distinguishes integrated payments, which leave onboarding, economics, and experience with the external provider, from embedded payments, which bring those functions into the platform.

PayFac-as-a-Service, or PFaaS, separates ownership of the merchant experience from responsibility for the payments infrastructure. The ISV gets white-labeled branding, control over pricing, ownership of the data, and merchant-of-record economics without having to register as a payment facilitator. The partner handles sponsorship, KYC/KYB, underwriting, and network compliance.

Full PayFac registration places those responsibilities directly with the ISV, which becomes merchant of record and assumes full liability in exchange for full control and economics. Setup and ongoing compliance are substantial, so this model requires meaningful annual processing volume to justify its cost. Control comes with an operating burden. Payroc’s April 2026 comparison, “ISV Payment Models Compared: Referral vs Gateway vs ISO vs PayFac,” frames the decision around sales control, risk and liability, and revenue opportunity.

What each model actually pays: the take-rate gap across identical processing volume

Diagram: The Take-Rate Gap: Same Volume, Vastly Different Revenue. Visualizes: Visualize the revenue contrast across four payment models applied to identical gross payment volume.

With the same gross payment volume, referral and PFaaS often bring in payments revenue that differs by 5–10x. No additional merchant is needed for that gap to appear. It comes from how much of each processed dollar the platform retains, rather than from a larger customer base or more transactions. Referral brings a low net basis-point return, integrated markup brings a moderate return, and PFaaS can bring in much more.

In the model comparison used for this analysis, full PayFac registration brings in fewer net basis points than PFaaS. The distinction is between gross control and net economics. Owning more of the payments operation can increase what the platform captures before costs without increasing what it retains after those costs.

Attach rate then multiplies the effect of take rate. Most platforms stall well below half of eligible merchants actively processing on-platform, leaving substantial volume outside the monetized payments layer. Getting more of the merchants already on the platform to use payments adds GPV without adding a new software customer. The product also influences the rate merchants will accept. Fitness studios often accept higher effective rates from platforms that handle scheduling and membership because they weigh what the software as a whole is worth to them.

Gross and net treatment can make the same underlying profit look very different in reported revenue and growth. Cash economics do not change with that presentation. When talking to investors, ISVs need to model both treatments while comparing the payment income they keep on the same basis.

Why fragmented or referral arrangements leak value beyond the rate they pay

The basis-point gap is only the starting cost. Referral and patchwork arrangements also send margin to third parties, scatter transaction data across disconnected systems, and leave part of the merchant relationship outside the platform’s control. These losses are linked but distinct. A platform can get a better residual through negotiation without getting the ownership of data or the merchant experience that comes with a deeper payments model.

Transaction data is the foundation for additional financial products. Platforms that own it can build credit, insurance, capital, and forecasting products on top of the payments layer. A referral relationship does not provide that same foundation. Fragmentation therefore limits more than reporting quality, because it leaves the platform without the unified transaction asset those products depend on.

When the processor owns onboarding and dispute resolution, the ISV is removed from events that can define the merchant’s trust in the platform. A chargeback or payout delay belongs to the processor’s operation, yet the ISV can lose trust while lacking control over the resolution. Responsibility and control have become misaligned.

Revenue leakage also grows with merchant activity. Subscription ARPU is flat by design, while payments ARPU inherits growth as merchants transact more. A small referral residual leaves most of that expansion with the processor rather than capturing the economics available through embedding. The cost is therefore not confined to today’s margin. Lost income, gaps in the data, and less ownership of the merchant relationship also affect what a buyer can value at exit.

How the payments layer changes what a platform is worth to a buyer or investor

Buyers look at how durable revenue is, how much it grows, its margin, and net revenue retention. Embedded payments can strengthen each dimension because revenue follows daily merchant operations rather than contract anniversaries, expands with usage, and is difficult to move without disrupting invoicing, reconciliation, and cash flow. The platform is monetizing an operating dependency.

Net revenue retention makes that distinction visible. NRR separates businesses that must replace lost revenue from those whose existing customer base expands on its own. As merchants grow, their activity can increase platform revenue without a change in subscription tier. That growth gives a buyer a reason to examine the payments layer separately.

Toast reported much higher financial services revenue than subscription revenue in 2025, so payments were a core part of how its restaurant operating system made money. ServiceTitan was capturing a meaningful take rate on a large volume of field services spend at its IPO. Affirm announced a multi-year partnership with ServiceTitan in September 2025, adding buy now, pay later to that financial services layer and using payments as a foundation for further monetization.

Xero’s June 2025 acquisition of Melio at a high multiple offers a different signal. The acquisition explicitly added embedded SMB payments to its accounting platform, showing the strategic value an acquirer can place on the payments layer. That rationale becomes more important as agentic workflows put pressure on seat-based SaaS models. Payments grow with consumption rather than seats and are less easily displaced by AI. The valuation premium is therefore a compounding of earlier choices, from model and take rate through attach rate and NRR to the multiple a buyer will pay.

The operational costs that referral avoids and embedding requires — and how PFaaS changes that trade-off

Full PayFac registration presents a legitimate operational objection to embedding. It requires significant upfront spending, meaningful annual maintenance, and a 12-to-18-month registration period. The registered facilitator is also directly responsible for merchant underwriting, dispute resolution, and card network compliance. This is not a minor software extension. Visa’s Acquirer Monitoring Program and Mastercard’s SMMP add monitoring obligations, including tight investigation windows for flagged merchants.

Faster onboarding does not remove the underlying exposure. Digital PayFac models have shortened approval times from weeks to minutes, but the risk of approving a fraudulent merchant remains. At scale, roughly 3% of newly digitally onboarded SMEs turn out to be fraudulent. What is a manageable queue at low volume becomes a structural workload as the portfolio grows. Any comparison that credits faster activation without accounting for fraud and compliance is incomplete.

PFaaS narrows the gap between referral’s simplicity and full registration’s economics. The partner handles sponsorship, identity and business checks, underwriting, and network compliance, while the ISV controls pricing, branding, data, and the merchant experience. It preserves most of the economic upside without requiring the platform to become a registered facilitator. Machine-learning-powered underwriting and KYB automation are also compressing onboarding timelines, allowing sub-merchant portfolios to scale without proportional increases in compliance headcount.

For most vertical SaaS platforms, that division makes PFaaS the appropriate middle path. It does not make operating costs disappear. The platform still has to pay for support, tooling, and the merchant experience, and how deep the program goes must fit its risk appetite. The selection rule is to choose depth when contribution margin at realistic attach rates funds the required operations.

How to model the actual revenue gap for a specific platform before making the model decision

The practical decision starts with the platform’s own merchant base. The relevant inputs are active paying SaaS accounts, the percentage processing in-app today, a realistically achievable attach rate, and average monthly volume per attached merchant. Average volume is industry-dependent and often underestimated by ISVs. Multiplying active accounts by attach rate and monthly merchant volume establishes the GPV available to monetize. Applying each model’s net take rate then shows the revenue difference on a consistent base.

That revenue comparison needs a cost layer. Clawbacks and fraud drag cut what the platform keeps, and the risk is greater in card-not-present environments. Support and tooling costs per attached merchant also rise with PayFac depth. These inputs turn a headline take-rate comparison into a contribution-margin comparison. They can make the five-to-ten-times revenue gap concrete or show why a particular platform’s realizable advantage is smaller.

To set an achievable attach rate, the platform needs to look at the product as well as its sales target. Platforms stall when checkout is not native, onboarding sits outside the workflow, or merchants have no incentive to switch. Fixing those obstacles is a product roadmap decision. The model should therefore show both today’s adoption and the adoption that a better embedded experience could realistically bring. Once merchants are attached, growth in their locations and transaction activity expands payments revenue without an incremental sales effort.

Pay Out, including accounts payable automation and disbursements, creates additional revenue and retention opportunities, while Pay Ops, including merchant onboarding and risk, deepens switching costs and the data asset. A full-stack strategy spanning Pay In, Pay Out, and Pay Ops on one infrastructure offers stronger economics than a piecemeal arrangement. The platform must choose a depth of ownership that can turn those opportunities into funded, durable contribution margin.

More in Embedded Payments Strategy