The economics of embedded payments for vertical SaaS

Payments stop being a line item the moment you own them. This paper models what changes in your revenue, your margin, and your retention numbers when payments move inside the product.

Most vertical SaaS platforms handle payments through a referral deal, and it made sense when they signed it: nothing to build, no compliance exposure, and a revenue line that cost nothing to open. Five years on, the same arrangement earns single-digit to low double-digit basis points on merchant volume, leaves the platform carrying the support burden, hands the merchant relationship to a third party, and adds an onboarding handoff that arrives in reporting as a software churn problem.

The gap is not marginal. Published industry analysis puts embedded economics at roughly five to ten times a referral arrangement on identical volume. Modelled from the inputs up, the illustrative example in Section 3 lands near fifteen times: a 1,000-merchant platform moves from roughly $90,000 a year in payments revenue under a referral deal to roughly $1.35 million under an embedded model, on the same book of customers.

That multiple decomposes into two inputs and nothing else. Roughly 3x comes from attach rate, moving from the teens to above 40 percent of eligible merchants. Roughly 5x comes from effective revenue share, moving from 10 basis points to 50. Attach rate is the input platforms treat as a sales problem when it is a product problem: if payments setup is a separate conversation with a separate vendor after go-live, it stays low, and if it is a step in onboarding, it climbs.

The cost side is where build versus buy actually gets decided, and it is systematically underestimated because most of it cannot be priced from a vendor quote. Sponsorship and network registration, merchant underwriting and KYC, ongoing risk monitoring, PCI-DSS scope, dispute handling, settlement and reconciliation, and capital held in reserve against merchant credit risk are calendar time and permanent headcount rather than line items. Industry guidance puts the crossover for a registered PayFac program somewhere north of $500 million in annual processing volume, and in practice higher once the headcount is priced honestly.

Revenue is what gets the project approved. Retention is what makes it strategic. A merchant whose money moves through the platform is not a software migration to displace, it is a treasury project, and published analyses of embedded finance in vertical SaaS report materially lower churn and higher revenue per customer for platforms with financial products attached. Churn moves a valuation multiple more than almost anything else on the page. Two caveats travel with that claim and are covered in Section 5: some of the retention lift is selection rather than causation, and payments margin has to be segmented from software margin before a buyer does it for you.

For most platforms, the answer sits at neither end of the spectrum. PayFac-as-a-Service leaves merchant boarding, brand, pricing control, and the majority of the economics with the platform while underwriting, compliance, and regulatory exposure sit with the partner. Full registered PayFac status is the right answer for a narrow set of platforms, and Section 6 sets out the axes that separate them from the rest.