Embedded Payments 101 for Software Platforms

If you build software for a vertical that takes money, you have four real ways to put payments inside your product: refer it out, resell a gateway, become an ISO, or go PayFac. Each one trades revenue for liability on a sliding scale. For most software platforms the right answer is the one in the middle that rarely gets named on a pricing page: managed PayFac, where you keep most of the PayFac economics and the embedded experience, but a sponsor carries the underwriting, compliance, and settlement liability you almost certainly don't want on your balance sheet. This guide maps the full spectrum so you can pick deliberately instead of defaulting.

This is builder-to-builder. We'll skip the marketing and treat payments as what it is for an ISV: a feature with a P&L, a risk surface, and an onboarding flow your users will judge you by.

Why payments became a product decision, not a checkbox

A decade ago "we accept cards" meant a Stripe key and a checkout button. Today, if your software is the system of record for a business, scheduling, invoicing, POS, marketplace, field service, payments is one of the largest revenue lines available to you, often larger than your software subscription. The processing economics on transactions flowing through your platform are real money, and your users would rather pay one vendor than reconcile two.

But that revenue comes attached to obligations: underwriting merchants, handling chargebacks and fraud, holding funds, KYC/KYB, and PCI scope. The four models below are really four different answers to one question: how much of that obligation do you take on in exchange for how much of the economics?

The four models, end to end

1. 1
   Referral. You hand off the merchant; the processor owns everything after.
2. 2
   Gateway reseller / ISV integration. Payments live inside your product; the processor still owns boarding and risk.
3. 3
   ISO. You sell and service merchant accounts under a sponsor bank.
4. 4
   Managed PayFac. The PayFac experience and most of the economics, while a partner carries underwriting, compliance, and reserves.

Think of it as a spectrum from "least liability, least revenue" to "most revenue, most liability."

1. Referral

You send your users to a payments provider and collect a referral or revenue-share. You touch no money, hold no compliance, and write almost no code. The provider underwrites and supports each merchant; your users sign up with someone else and may experience a hand-off that feels bolted on.

• You get: a small, passive share with near-zero effort.
• You give up: the embedded experience, the data, and most of the margin.
• Good when: payments is tangential to your product, or you're testing demand before investing.

2. Gateway reseller / ISV integration

You integrate a gateway's APIs so cards are processed inside your UI, and you resell under a wholesale arrangement. The experience is embedded; the merchant relationship and underwriting still sit largely with the processor or an ISO partner. You earn more than referral because you're doing real integration work and owning the UX.

• You get: an in-product experience and a better revenue share.
• You give up: control over onboarding speed and pricing; you're a feature on someone else's rails.
• Good when: you want embedded UX without standing up a payments operation.

3. ISO (Independent Sales Organization)

As a registered ISO you sell and service merchant accounts under a sponsor bank and processor. You own pricing, the merchant relationship, and a larger residual. You generally do not take settlement or balance-sheet liability the way a PayFac does, the processor still settles to merchants, but you carry sales, support, and program obligations, and registration with the card networks.

• You get: pricing control, the merchant relationship, and meaningful residual income.
• You give up: time and overhead to register and run a sales/support organization; onboarding still uses traditional merchant applications unless you build on top.
• Good when: payments is core, you want pricing flexibility, and you don't want full PayFac liability.

Relyon operates here: a retail-sales ISO (the sales arm), with processing on Fiserv and TRX (TrxServices, an ISO/MSP of Metropolitan Commercial Bank, Member FDIC). We sell and service; the bank and processor handle settlement and the regulated functions.

4. PayFac (Payment Facilitator), and managed PayFac

A true PayFac becomes the master merchant. Your sub-merchants onboard under your account, you control onboarding end to end, you can fund near-instantly, and you capture the richest economics. You also inherit the full weight: network registration, sub-merchant underwriting, KYC/KYB, transaction monitoring, chargeback and fraud liability, funds-flow and reserve management, PCI DSS at the highest scope, and ongoing compliance. Building this is a multi-quarter, multi-headcount commitment before a dollar moves.

Managed PayFac (also called PayFac-as-a-service or facilitator-as-a-service) gives you the PayFac experience and most of the economics while a sponsor or platform partner carries the heavy liability: underwriting, compliance, funds flow, and reserves. You get instant-feeling onboarding, sub-merchant management, and split/instant funding, without registering as a facilitator or staffing a risk department.

• You get: PayFac-grade embedded onboarding and strong economics.
• You give up: a slice of margin to the partner who carries the liability, usually a bargain versus the cost and risk of doing it yourself.
• Good when: you want control and revenue but not a compliance org. This is the sweet spot for most ISVs.

The revenue-vs-liability tradeoff at a glance

Read this table as a choice, not a ranking. A platform where payments is a side feature is right to stay at referral. A platform where payments is the business may justify full PayFac. The center two rows are where most software platforms find the best ratio of dollars earned to risk and effort assumed.

Why managed PayFac is usually the sweet spot

The instinct is to read the table left to right and conclude "more revenue is better, so go full PayFac." That ignores what the rightmost column actually costs. Full PayFac liability isn't a line item, it's an operating capability: a risk team, monitoring systems, reserve capital, audit cadence, and the standing exposure that a few bad sub-merchants can become your loss.

Managed PayFac decouples the two things you want (control and economics) from the one thing you mostly don't (carrying the liability yourself). You ship the same embedded onboarding and funding experience your users would get from a full PayFac, you keep economics far closer to PayFac than to referral, and a partner absorbs underwriting, compliance, and funds-flow risk. For a software team whose core competency is the vertical, not transaction monitoring, that's the rational trade: keep building product, let specialists carry the regulated load.

The honest caveat: you give up a margin slice to that partner, and you should price it against the fully loaded cost of doing it yourself, headcount, systems, capital, and tail risk, not against the partner's fee in isolation. Run that comparison with real numbers. For most ISVs it favors managed PayFac by a wide margin.

Where embedded AI onboarding changes the math

Whatever model you choose, the moment your users feel it is onboarding. Traditional merchant applications, PDFs, re-keyed data, days of back-and-forth, opaque approvals, make even a great platform look like it bolted payments on. Onboarding is where embedded payments is won or lost.

Embeddable AI onboarding closes that gap. Done well, it pre-fills applications from data you already hold, validates KYB details and surfaces issues before submission, explains pricing in plain language, and gives applicants a clear, real-time status instead of silence. Crucially for an audit-grade approach, every automated step leaves a trail: what was collected, what was checked, and why a decision was reached, so faster onboarding doesn't mean less defensible onboarding. That's intelligence with an audit trail, not a black box.

The strategic payoff for an ISV: the experience inside your product becomes the differentiator. A merchant who onboards in minutes, in your UI, with transparent pricing and a visible status bar perceives a best-in-class platform, even when a sponsor and processor handle the regulated machinery behind the scenes. Managed PayFac supplies the economics and the embedded rails; AI onboarding supplies the polish that makes the whole thing feel native.

How to choose

Start from your product, not the org chart. Ask three questions:

1. How central is payments to what we sell? Tangential favors referral or gateway; central favors ISO or managed PayFac.
2. How much liability can we actually operate? Be honest about whether you can staff and capitalize risk. If not, managed PayFac lets you have the experience without the exposure.
3. Where do our users feel the product? If onboarding and funding are part of your value story, prioritize models, and partners, that let you own that experience, then make it shine with embedded AI onboarding.

The goal isn't to climb to the highest-revenue model. It's to land on the row where the revenue you capture, the liability you carry, and the experience you control are all in proportion to your business. For most software platforms, that row is managed PayFac with embedded, transparent, AI-assisted onboarding on top.