What an ISV is, and why software companies became payment companies
An independent software vendor — ISV — is a company that sells software it wrote to businesses that use it to run something else: a veterinary practice, a landscaping crew, a self-storage facility, a youth sports league. For most of the last two decades the ISV's revenue was a subscription, and the payments its customers took happened somewhere else, through a processor the customer found on its own.
Two forces dismantled that arrangement. The first is arithmetic: the money flowing through a vertical software product is typically an order of magnitude larger than the subscription charged for it. A platform billing a contractor a few hundred dollars a month may be watching that contractor collect several hundred thousand a year, so capturing even a thin slice of the payment margin can exceed the software line outright. In the clearest public example, Toast, processing revenue is the large majority of what the company earns and the point-of-sale software is what makes it possible.
The second force is that customers prefer it. A merchant onboarded inside the software it already uses, with deposits that reconcile against the invoices in that same software, has a materially better experience than one juggling a separate processor, a separate statement and two systems that disagree about what was collected.
The monetisation ladder: four rungs, four sets of obligations
There are only four structural choices available to a software company, and they form a ladder. Each rung earns more per dollar processed, requires more of the platform, and takes longer to stand up.
| Referral | Revenue share | PayFac-as-a-service | Full PayFac | |
|---|---|---|---|---|
| Who underwrites the merchant | Processor | Processor | Provider, sometimes shared | The platform |
| Who sets merchant pricing | Processor | Usually the processor | The platform | The platform |
| Whose brand the merchant sees | Processor | Both | The platform | The platform |
| Who absorbs unrecovered losses | Processor | Processor | Provider, usually with recourse | The platform |
| What the platform must have first | A salesperson | A contract | Onboarding UX, support, a risk owner | Registration, sponsorship, PCI Level 1, risk operations, capital |
| Revenue shape | Bounty or thin residual | Residual on margin | Spread over a buy rate | Full margin less cost of operating |
| Realistic time to launch | Days | Weeks | One to two quarters | A year or more |
The concept governing everything from the second rung upward is the buy rate: the wholesale per-transaction cost the provider charges the platform, generally interchange plus network assessments plus the provider's own margin. Whatever the platform charges merchants above that is its revenue; everything below is a cost it cannot influence. Ask for the buy rate as a formula — which components pass through at cost, which carry markup, what triggers a repricing — because a blended number conceals which part of the stack is negotiable.
The mistake most platforms make is skipping rungs. A company with two hundred merchants and nobody whose job is payment risk does not need its own network registration. It needs attach rate.
Attach rate is the number that decides the outcome
Attach rate is the share of a platform's customers who actually process payments through the platform rather than through some outside provider. It is the single most powerful variable in embedded payments, and it is routinely neglected in favour of negotiating basis points.
Work a hypothetical. A vertical platform has 600 customers. Half process through the product — a 50% attach rate, respectable for a well-integrated product and optimistic for a bolt-on. Each processes $25,000 a month, so the portfolio is $7.5 million a month, or $90 million a year. Now apply retained margin, expressed in basis points, meaning hundredths of a percentage point of processed volume:
- At 10 bps — a thin referral arrangement — roughly $90,000 a year. A rounding error against payroll, correctly treated as incidental income.
- At 40 bps — a competently negotiated PayFac-as-a-service spread — roughly $360,000, at which point payments deserves an owner and a roadmap.
- At 75 bps — the upper end of what full facilitation retains on a favourable mix — roughly $675,000, against a fixed compliance and risk cost base that can consume much of the difference between that and the 40 bps figure.
Those numbers are illustrative, not quotes. The structural point holds at any scale: moving attach from 50% to 70% at 40 bps beats moving margin from 40 to 50 bps at 50% attach, and it requires no registration, no sponsor bank and no risk hire. The highest-return work in most embedded payments programs is making payments the default path in onboarding rather than a setting somebody has to find, collapsing the merchant application into the existing signup, and building reconciliation that matches the invoices already in the product.
Why payments revenue can exceed software revenue — and why that is not free
Take the same platform and compare the two lines. If those 600 customers each pay $400 a month for software, annual subscription revenue is $2.88 million. Total payment volume across the attached half is $90 million — thirty times the software line. At 40 bps the platform captures $360,000, roughly an eighth of subscription revenue. Push attach to 80% and merchant size up modestly, and the payments line starts approaching the software line. Push the platform into full facilitation on a card-heavy, small-ticket mix and payments can pass it.
Two honest caveats belong next to that arithmetic, and vendor material rarely includes them.
First, payments revenue carries a far lower gross margin than software revenue. Most of the headline number is somebody else's cost — interchange, assessments, the provider's margin — and what remains has support, risk, reconciliation and loss against it. A platform reporting payments revenue gross of those costs is presenting a figure investors discount heavily. Track net revenue after cost of payments and report it that way internally from the beginning.
Second, payments revenue is more volatile. It moves with the merchant's own trading, so seasonality, recessions and one large customer's bad quarter pass straight through. It also couples churn: a merchant that leaves takes both lines with it, which flatters retention while things go well and amplifies the damage when they do not.
Underwriting and sub-merchant onboarding: the obligations behind the money
Payment revenue arrives attached to work, and the work is regulatory rather than technical. Once a platform boards merchants as sub-merchants — accounts opened underneath somebody's master merchant registration — a set of obligations attaches, and it attaches whether the platform is a full facilitator or renting somebody's registration.
- Know your business. Legal entity verification, beneficial ownership, the nature of the business and what it actually sells. The application form is a compliance artifact a sponsor bank will audit, not a signup screen.
- Screening. Sanctions lists and the card networks' terminated merchant file, repeated on a schedule rather than performed once at onboarding.
- Credit assessment, which most platforms misread. Card risk is not fraud risk. The dominant exposure is delivery lag: if a merchant collects today for something it delivers in six months and then fails, its customers charge back and somebody upstream pays. Deposits, prepaid packages, events, travel and annual memberships are high-exposure patterns regardless of how honest the merchant is.
- Ongoing monitoring. Average ticket drift, volume spikes, chargeback ratios approaching network thresholds, and patterns consistent with laundering.
- Dispute operations and support. Somebody must answer chargebacks with evidence on a deadline — and the moment your logo is on the checkout, merchants call you, not the processor whose name they have never seen.
- Funds handling. Passing settlement straight through is one thing; holding balances is another, and it raises money transmission licensing questions that belong with counsel rather than with an engineer's intuition about escrow.
Even where a provider carries first loss, recourse clauses typically push portfolio losses back to the platform, and providers generally reserve the right to hold funds or establish reserves at their own judgement. Read those clauses before assuming the risk sits somewhere else.
The providers, and the categories people confuse with them
The PayFac-as-a-service market is genuinely competitive, and the providers differ in ways that change the model rather than just the price.
- Finix is a full-stack acquirer-processor with direct network connections, priced as subscription plus per-transaction fees and stating that it does not mark up interchange — a structure that produces a very different cost curve as volume grows than a percentage-of-volume deal. It serves the United States and Canada only.
- Payrix, now sold as Worldpay for Platforms and part of Global Payments, offers the sponsorship, balance sheet and acquiring licences of a top-tier acquirer. The counterweight is corporate churn: it changed owner three times between 2022 and 2026 and its brand was retired along the way.
- Rainforest competes explicitly on platform economics, portfolio migration off an incumbent, and a contractual data-portability commitment. It is young and venture-backed, so continuity risk sits higher than with an acquirer-owned competitor, and its terms allow it to establish reserves at its own reasonable judgement.
- Moov publishes per-service pricing and puts money in and money out on one ledger — card acceptance alongside ACH, RTP, FedNow and push-to-card — which suits platforms that disburse as well as collect. Its liability cap is narrow, and procurement should read it.
- Stripe and Adyen both sell platform products for onboarding and monetising sub-merchants, and for many teams they are the default. The trade is how much of the pricing, funding timing and merchant relationship the platform genuinely controls.
Three adjacent categories get mistaken for this one, and buying the wrong one wastes a quarter. Chargebee and Recurly are subscription billing: they run plans, invoicing, dunning and revenue recognition on top of a merchant's own gateway. They do not acquire, do not settle and carry no chargeback liability, so they solve a billing-logic problem and add no payment revenue. Spreedly is orchestration and a card vault — valuable for holding tokens outside a processor so migration stays possible, but it never touches the money. Paddle is a merchant of record, close to the opposite of embedded payments: it becomes the legal seller and carries global tax registration, so the vendor gives up the customer relationship rather than acquiring one. Excellent for a small vendor selling worldwide with no finance function; wrong for a platform trying to own its merchants.
When a software company should not do this
Most material on this subject assumes the answer is yes and argues only about which rung. It is worth stating the cases where the honest answer is no, or not yet.
- Your merchants are large. A customer processing tens of millions a year will negotiate a better direct acquiring deal than you can offer, needs a merchant account in its own name for treasury and audit reasons, and will resent being aggregated. Refer these customers and keep the relationship.
- The portfolio is too small to cover the fixed cost. Payments is not a feature; it is a product line with support, risk, reconciliation, dispute handling and its own engineering backlog. If projected net revenue does not cover a person and a half, it is a distraction from the software roadmap.
- Payments is not already in the workflow. If your product does not produce the invoice, the appointment or the order, payments will be a bolt-on and attach will be low. Fix the workflow first; monetisation follows it, never the reverse.
- Your vertical is high risk, or delivery lags badly. Platforms serving travel, events, ticketing, deposits and long-dated prepaid services take on credit exposure that looks like nothing until one merchant fails.
- Nobody will own risk rather than revenue. The role that declines business the sales team wants has to exist and has to win the argument. If it will not, PayFac-as-a-service is your ceiling — a perfectly good place from which to run a large business.
Referral is also a legitimate permanent answer, not a failure state. It costs nothing, breaks nothing, and leaves the software company doing what it is actually good at.
What to negotiate, and the one number to watch monthly
Whatever rung you choose, a handful of clauses determine whether the arrangement survives success.
- Buy rate as a formula. Components identified, pass-throughs distinguished from markup, and a defined trigger for repricing.
- Volume-based improvement. A mechanism that improves your rate as the portfolio grows, rather than a fixed rate held flat for a five-year term.
- Portability. An explicit right to export merchant records, transaction history and payment tokens in a usable format. Tokens that cannot leave the vault turn every future negotiation into a re-onboarding project, which is exactly why the incumbent is comfortable.
- Term and exclusivity. Shorter than feels comfortable, with a defined exit and no automatic multi-year renewal.
- Loss and reserve mechanics. Precisely which losses are recourse to you, how reserves are sized and released, and what notice you get.
- Change of control. The right to renegotiate or exit if your provider is acquired. In this market that is not a hypothetical.
Then instrument one metric and review it every month: payment revenue per active customer, net of cost of payments. It compresses attach rate, retained margin and churn into a single figure, and it answers the only question that matters — whether to climb the ladder or stay exactly where you are.
Frequently asked questions
What is an ISV in payments?
An independent software vendor is a company that sells software to businesses that use it to run their operations — practice management, field service, property management, scheduling. In payments, ISV usually means such a company that also offers payment acceptance inside its product, either by referring customers to a processor or by monetising the payments itself through a revenue share or a payment facilitator arrangement.
What is the difference between a referral partnership and PayFac-as-a-service?
In a referral arrangement the processor underwrites, prices, funds and supports the merchant, and the software company is paid a bounty or a thin residual for the introduction. Under PayFac-as-a-service the provider holds the network registration and sponsorship, but the software company boards its own sub-merchants, sets their pricing, controls the experience and keeps the spread over a wholesale buy rate. The second earns far more and requires onboarding, support and risk capability the first does not.
What is a good attach rate for embedded payments?
Attach rate is the share of a platform's customers who process payments through the platform. Rates vary widely by vertical and by how tightly payments is woven into the workflow: a bolt-on offered as an option in settings commonly attaches at a low fraction of customers, while a product where the platform generates the invoice or the order can attach a clear majority. Improving attach usually moves total payment revenue more than renegotiating margin does.
Can payments revenue really exceed software revenue for a SaaS company?
Yes, and it does for several public companies, because total payment volume through a vertical product is typically many times larger than the subscription charged for it. The important qualification is margin: payments revenue reported gross includes interchange and provider costs that the platform never keeps, and the retained portion carries support, risk and loss expense. Net of those costs it is a real but lower-margin, more volatile line than subscription revenue.
Does a software platform need to become a registered payment facilitator?
Most do not. Full registration requires a sponsor bank relationship, card network registration, PCI DSS Level 1 assessment, underwriting and monitoring staff, dispute operations and capital held against portfolio losses — costs that are largely fixed and therefore punishing below a certain portfolio size. PayFac-as-a-service delivers most of the control and much of the margin without those obligations, and is the right permanent home for many platforms.
Who is liable when a sub-merchant fails and its customers charge back?
Ultimately the party holding the merchant registration, which means a full payment facilitator pays out of its own funds. Under PayFac-as-a-service the provider generally absorbs first loss but retains contractual recourse to the platform, and typically reserves the right to hold settlement funds or establish reserves. The exposure is driven mainly by delivery lag — how far in advance of delivery the merchant's customers pay — rather than by fraud.
When should a SaaS company not embed payments?
When its customers are large enough to negotiate better acquiring deals directly, when the portfolio is too small for retained revenue to cover a dedicated support and risk function, when payments is not already part of the product's workflow so attach will be low, or when nobody in the company is willing to own payment risk against the sales team. In those cases a referral arrangement earns less but costs almost nothing, and it is a legitimate permanent choice.