Stripe processed over $1 trillion in payments in 2023. For most vertical SaaS teams building their first embedded payments flow, Stripe Connect is the obvious starting point. It handles KYC, 1099 tax forms, and enough of the compliance surface that most SaaS engineers never have to think about it. You can ship a working payout flow in a weekend.

That speed is real. For early-stage products it usually makes sense. The problem shows up later, when the payout rail starts to interact with the rest of your product and your vendors' businesses.

The more useful question is which point on the payments ownership curve a platform actually sits at, and when it makes sense to graduate to the next.

The Four Levels of Payments Ownership

Embedded payments looks like a single decision from the outside. From the inside it splits into four distinct models, each with different economics, compliance burden, and chargeback exposure.

The first is the referral or ISO model. The platform refers merchants to a processor, takes a small share of the spread, and carries no liability. Stripe Connect Standard sits here for many early-stage platforms. Onboarding is fast, the processor owns the merchant relationship, and the platform's take rate is thin.

The second is Payments-as-a-Service, sometimes called PayFac-as-a-Service. The platform looks like a payment facilitator to its merchants, but the underlying license, sponsor bank, and core compliance work sit with the provider. This is where Stripe Connect Custom (now Embedded Components), Adyen for Platforms, Finix, Payrix, Tilled, Embed, and Rainforest operate. Margins are materially higher than referral. The platform takes on more compliance work and more chargeback exposure than at level one.

The third is registered Payment Facilitator. The platform holds its own PayFac registration with the card networks, runs its own sponsor bank relationship, and operates its own underwriting. Toast is the canonical vertical SaaS example at this level. Margins are highest. So is the compliance lift: KYB at scale, AML, OFAC screening, SAR/CTR filings, reserve management, and direct chargeback liability.

The fourth is acquirer or processor. Almost no software company sits here. It exists for completeness.

Most vertical SaaS platforms graduate from level one to level two when payment volume hits a certain inflection. The question is whether the next step on the ownership curve produces enough margin to cover the operational work it adds.

Why Stripe Connect Is the Default Starting Point for Vertical SaaS Payments

Stripe Connect launched over a decade ago specifically to handle marketplace and platform payouts. It covers merchant onboarding, identity verification, tax reporting, and cross-border payments in a single integration. For a team that needs to ship fast and doesn't want to think about payment compliance, that breadth is genuinely useful.

The developer experience is also hard to argue with. Stripe's documentation is thorough, the SDKs are mature, and there's a large community of engineers who've already solved common integration problems. When you're building your first version, that head start matters.

Connect itself is not one product. Connect Standard, Express, and Custom (Embedded Components) sit at different points on the ownership curve. Standard is closest to a referral relationship. Custom can support a near-PayFac experience with material take rate via application_fee_amount on direct charges. Teams that say "we use Connect" often mean very different things, and the economics differ accordingly.

Cross-border is genuinely Stripe's strongest moat. Connect supports payouts in 45+ countries with FX handling that purpose-built alternatives still struggle to match. For platforms with a global vendor base, that coverage is hard to walk away from.

But Stripe Connect was built for a wide range of use cases, not specifically for vertical SaaS platforms. That distinction becomes important at scale, and it shows up in three places: the economics, the accounting integration, and the underwriting model.

Purpose-Built Embedded Payments Providers for SaaS Platforms

A separate category of providers has grown up specifically for vertical SaaS, and the difference in design philosophy is meaningful.

Rainforest is one example. It operates as a Payments-as-a-Service provider: platforms own their customer relationships, data, and contracts, and earn a share of the payment margin rather than passing it entirely to the processor. Rainforest also builds vertical-specific underwriting models, which matters for industries like healthcare, home services, and logistics where merchants don't fit the standard risk profile and end up with low approval rates under mainstream processors. The company raised a $29 million Series B in September 2025 and counts healthcare, nonprofits, and home services as its fastest-growing segments.

The competitive set is wider than Rainforest. Adyen for Platforms is the enterprise default and powers payments for eBay, Uber, and Microsoft. Finix is the closest direct comp on developer-first PFaaS positioning. Payrix sits inside FIS and is deep in vertical SaaS. Tilled and Worldpay for Platforms round out the list. Each operates broadly at level two of the ownership curve, with different geographic coverage, pricing, and underwriting depth. The right choice depends on the vendor profile.

Embedded banking is an adjacent category. Unit and Column extend further into business accounts, cards, and lending alongside payout rails. They are not direct alternatives to Stripe Connect for processing, but they are often the next expansion line for a platform that has already shipped payments.

The full landscape is wider still. The Open Banking Tracker tracks 96 embedded payments providers across both processing and banking infrastructure.

The Revenue Case for Switching Off Stripe Connect

This is the part most vertical SaaS teams underestimate, and the framing matters.

Stripe Connect does support a platform margin via application_fee_amount. The cap on that margin is what differs from a PFaaS or registered PayFac model. Platforms on Connect Standard typically capture a thin share of the spread. Platforms that move to level two of the ownership curve capture meaningfully more, both because the fee structure is different and because they participate in interchange-plus economics directly.

A 2022 Bain & Company and Bain Capital report forecast total embedded finance transactions in the US to exceed $7 trillion by 2026, with payments as the largest category. UBS puts SMBs at 25-30% of US payment volume but over 70% of net revenues. That's the market vertical SaaS platforms sit closest to.

The conventional wisdom is that take rates are compressing toward zero. Rainforest's 2026 Embedded Payments Benchmark, presented at Vertex, reports a different pattern: nearly half of vertical SaaS platforms in the survey report take rates above 90 basis points. Platforms processing under $50M run median take rates of 0.46-0.60%; cross $250M in volume and the median doubles to 0.91-1.05%. This is vendor-published data from a sample of platforms that opted into the survey, so the numbers should be read directionally rather than as a universal benchmark. Even so, the ladder is consistent with what other PFaaS providers report, and it matches the broader pattern that payments economics inflect with scale.

There's also a retention argument. Platforms that embed payments well see higher retention because the payment experience is tightly integrated with the core product. A vendor who processes invoices, tracks jobs, and gets paid all inside the same tool is less likely to churn than one who toggles between your software and a generic payment interface. The same benchmark found that payments peaks at 35% of total platform revenue at 3-4 years after launch, making it one of the largest revenue lines in the business by that point.

Take Rate and Attach Rate: The Two Numbers That Define the Business Case

Two metrics determine whether embedded payments becomes a real revenue line or stays a feature: take rate and attach rate.

Take rate is the percentage of payment volume the platform keeps. The actual mechanic behind a 70-100 bp take rate is interchange-plus pricing on the merchant side, level 2 and level 3 data on B2B card volume, surcharging where legal, and merchant mix. The headline rate compresses or expands based on how those levers are set. At $100M in annualized payment volume, 70 basis points is $700K in annual revenue. At $500M it's $3.5M.

Attach rate is the percentage of a platform's active customers who actually adopt the embedded payments product. A strong take rate with a low attach rate doesn't move the needle. Platforms that reach strong attach rates typically get there by making payment collection the natural next step inside an existing workflow (job completion, invoice approval, order fulfillment) rather than a separate module the vendor has to discover and sign up for. Field service platforms that tie payment collection directly to job closeout consistently outperform those that treat payments as a standalone product.

The two numbers compound. There's a third variable the benchmark data surfaces: ownership. Platforms with a C-suite payments leader post almost double the take rates of those with no dedicated leader. Take rate, attach, and revenue share don't drift upward on their own.

52% of vertical software companies in the study still have no embedded fintech beyond payments at all. For platforms that have already shipped payments and are looking for the next revenue line, that gap represents the clearest expansion opportunity in the market right now.

For a fuller picture of how embedded payments fits the broader embedded finance landscape, Apideck's State of Embedded Finance 2026 report covers take rates, attach rates, and build vs. buy signals across 15 embedded finance categories and 200+ providers.

Which Verticals Feel This Most

Field service and home services platforms are the clearest case. Contractors and tradespeople are running businesses where the payout cycle is tightly connected to job completion and invoicing. Getting paid through the same platform where they manage their jobs, then having that payout flow automatically into their accounting software via ledger sync, is a core workflow.

Healthcare SaaS is another high-signal area. HSA/FSA payments, patient billing, and provider payouts all involve compliance and reconciliation complexity that generic payment processors handle poorly. Rainforest has cited an HSA/FSA authorization-rate lift from below 30% to 94% through vertical-specific underwriting, though most decline issues in this category come from MCC coding and IIAS compliance rather than underwriting alone, so the magnitude of any specific lift depends heavily on the starting baseline.

Legal SaaS is a third. Clio, which builds practice management software for law firms, launched Clio Payments in 2022. It now processes billions of dollars annually and was a significant driver of the company doubling ARR from $100M to over $200M between 2022 and 2024. In a SaaStr interview, CEO Jack Newton said that in hindsight, Clio should have invested in payments earlier and more aggressively. Legal payments carry their own compliance complexity, specifically trust accounting rules that require payments to be withdrawn from a separate operating account. Generic processors don't handle this. A purpose-built integration does. At the Vertex conference in April 2026, leaders from Clio and Toast covered what they learned the hard way building embedded fintech into their platforms.

Staffing, nonprofit management, and local government SaaS round out the picture. Any vertical where the end user is a small operator, payment flows are tied to operational workflows, and reconciliation happens inside accounting software is a candidate for a purpose-built approach.

The Payout Reconciliation Problem Most Vertical SaaS Teams Miss

The moment a payout hits a vendor's books, reconciliation starts. Someone has to match the payout to an invoice, confirm the amount is correct, and make sure it lands in the right account in whatever accounting software the vendor runs.

Stripe's data model is not built for this. It exposes transaction records, but those records don't map cleanly to what accounting software expects. You end up building a sync layer that translates Stripe events into general ledger entries (what the industry calls ledger sync), and that layer becomes a maintenance burden and a source of bugs every time either Stripe or the accounting platform changes its API.

Most teams scope the payout rail. Almost none scope the ledger sync. The fix requires treating the accounting integration as a first-class problem, not an afterthought. A unified accounting API handles the translation into each platform's data model automatically, so vendors don't have to manually reconcile payouts at month end. The data flows into their accounting software matched to the right accounts, without anyone touching it.

For a vertical SaaS product serving vendors who are also running a business, that's the difference between a tool that creates work and one that removes it.

How to Pick Your Payout Stack

Start with geography. Stripe Connect supports payouts in 45+ countries with mature FX handling. Most PFaaS alternatives have narrower coverage. If your vendor base is concentrated in the US, that gap matters less. If you serve global vendors, it can be the deciding factor.

Then look at chargeback and compliance liability. Connect Standard keeps both with Stripe. Moving to a PFaaS or to registered PayFac shifts liability onto the platform: chargeback reserves, dispute operations, KYB at scale, AML, OFAC screening, and reserve management all become operational work the platform owns. The margin gain is real, the operational lift is also real, and platforms that move too early end up running compliance functions they did not budget for.

Then look at your vertical's risk profile. If your merchants are in industries that mainstream processors treat as high-risk, a purpose-built provider with vertical-specific underwriting will deliver meaningfully better approval rates. That directly affects payment adoption inside your platform, which affects the revenue case.

Then look at the buyer experience. Stripe Link, network tokenization, and Radar set a high bar on the buyer side. Some PFaaS alternatives match it. Others do not. For platforms whose vendors are processing high transaction volumes, this can move conversion several points.

Finally, consider the option you may not have priced in: renegotiating inside Stripe. For platforms above a certain volume threshold, Stripe will negotiate a platform pricing arrangement that shares margin. Many companies that "switch off Connect" actually just move to a custom Stripe deal. Worth pricing both before assuming a migration is the only path to better economics.

The payout rail is one decision. The ledger sync is a separate one that most teams make too late. If your vendors run on QuickBooks, Xero, Sage, or any other platform, a unified accounting API lets you connect the payout output to their books without building per-platform sync logic. Scope both before you ship.