Embedded Payments Revenue Models for Vertical SaaS

Embedded payments revenue models for vertical SaaS determine how much a platform earns from the money moving through its software. Referral, markup, and PayFac-as-a-Service can produce substantial revenue differences on identical transaction volume. Model selection is therefore the highest-leverage payments decision, and the right choice balances margin capture with the platform’s capacity to manage operations and risk.

Why the revenue model matters more than volume

Volume magnifies the economics a platform has chosen. It does not repair them. Referral arrangements leave a thin net margin on gross payment volume, while PayFac-as-a-Service delivers several times more from the same transactions. Shopify’s FY2025 10-K shows that merchant solutions, including embedded payments, lending, and banking, account for roughly three-quarters of total revenue. Toast’s payments revenue likewise dwarfs its subscription line, demonstrating how deeply payments can reshape a software business. Given identical volume, which model should a platform choose, and when?

How take rate converts volume into actual revenue

GPV measures the amount processed, while take rate determines how much of that amount becomes platform revenue. Attachment rate measures how much of the eligible merchant base actually processes on-platform. A favorable take rate cannot monetize transactions that remain outside the platform, and a large customer base does not automatically produce large GPV.

That makes attachment an operational lever. Moving existing merchants onto embedded payments adds volume without adding a new logo. The recommended fix is deeper integration into the quote, invoice, or booking confirmation that merchants already use. A secondary payments menu leaves that connection weak. For investors, revenue recognition also affects how the resulting revenue line should be read, so reported revenue belongs beside GPV, take rate, and attachment when assessing the business.

What the referral and ISO model actually pays out

The referral and ISO model provides the fastest launch and the lowest-revenue starting point. The platform refers merchants to a processor and receives a residual fee. It does not underwrite merchants, hold merchant accounts, handle compliance, or own the relationship with the merchant. The operational commitment is correspondingly small and straightforward. That makes referral a legitimate option for an early platform with few merchants and no payments engineering capacity.

The trade-off is control over the resulting economics. The processor owns pricing and merchant data, leaving the platform unable to adjust take rate, customize the payment experience, or bundle payments with its software features. As volume grows, the revenue forgone relative to an embedded model grows with it. Referral is therefore a staging point for a platform as its payments business matures. A team starting here should decide what will trigger graduation, with fee-on-top markup as the next step toward keeping more of the margin itself.

The integrated markup model: a step up that still leaves margin on the table

The integrated markup model lets the platform charge more than it pays for processing and keep the spread. This produces a meaningful revenue improvement over referral. However, underwriting, merchant accounts, and compliance still depend on a third party, while pricing flexibility and control over the merchant experience remain limited. Without ownership of that relationship and deeper product integration, attachment stays constrained and pricing tends to follow competing processing rates, with limited scope to reflect total software value. The model is a useful transition, but it cannot deliver the full margin capture, merchant-level data, and branded onboarding available through PayFac-as-a-Service.

How PayFac-as-a-Service delivers near-full economics without full PayFac liability

PayFac-as-a-Service gives platforms much of a payment facilitator’s economics and control without requiring them to build and register a full PayFac. The platform gets higher net basis points, branded onboarding, merchant-level data, and more freedom to set pricing. The provider retains regulatory responsibility and handles risk management. For most vertical SaaS platforms, this split offers a better balance than earning little from referral or taking on the work of full registration.

The difference also appears in time to revenue. PFaaS can go live in one to four months, compared with 12–18 months for full PayFac registration. A broader full PayFac build can require 12–24 months, acquiring bank relationships, and infrastructure investment running into the hundreds of thousands to millions of dollars. PFaaS lets a platform keep more processing margin because the provider supplies the infrastructure and takes on the duties that would otherwise hold up launch.

The strongest structure unifies acceptance, disbursements, and payment operations. These functions are Pay In, Pay Out, and Pay Ops, with the last covering merchant onboarding, risk, and billing. One API connects them, so the platform does not need to work with three separate vendors. Due diligence should establish whether the contract provides a true processing-margin revenue share or a fixed referral fee with better branding, and whether the platform can set merchant pricing above provider cost and retain the spread. Before contracting, the platform should also obtain a written boundary covering the provider’s payment card data security compliance scope, KYC/AML onboarding, and fraud prevention responsibilities, as well as obligations that remain with the platform.

When full PayFac registration makes sense and what it actually costs

Full PayFac registration gives the platform the highest take rate and the most control over its relationship with the merchant. It gives the platform merchant-of-record status, all transaction data, full control over pricing, and the ability to underwrite sub-merchants directly. That authority can support approvals in minutes rather than the many days typical of traditional approaches. The operating burden rises with that authority. Substantial setup costs are followed by dedicated compliance staffing and risk management specialists, making this primarily an operational investment that also includes a technology build.

The rational crossover arrives when margin shared with a managed provider exceeds the cost of running registration, compliance, and risk infrastructure internally. Timing complicates that calculation because registration cannot begin and end at the instant the economics turn favorable. A platform expecting to cross the threshold within a year must account for the lead time. Toast illustrates the ambition at the far end of this spectrum. Its restaurant management platform has full payments infrastructure, but building it took years and resources that most vertical SaaS platforms do not have at launch.

How merchant onboarding speed and risk management determine whether any model performs

Slow or opaque onboarding suppresses attachment, delaying both processing volume and the first payment. A PayFac that sets its own underwriting rules can approve new businesses in minutes, while traditional approaches usually take many days. The economic benefit comes from well-designed compliance infrastructure.

The recommended operating approach is progressive and tiered underwriting. Initial sign-up can collect a business name, email, and basic use case, with further information requested as merchants commit to going live or reach volume thresholds. Merchants with lower risk can get automatic approval, while those in higher-risk verticals or with large volumes go through enhanced review. Review depth follows risk and merchant commitment. ACH brings its own compliance needs because platforms may fall under NACHA’s definitions of Third-Party Service Provider or Third-Party Sender and have to meet specific rules for registration, audits, and agreements.

Pricing strategy across card, ACH, and mixed-volume portfolios

Card and ACH require different pricing architectures because they contribute differently to the portfolio. Card volume is almost always more valuable, so platforms should make it the path of least resistance while retaining ACH as a real, well-priced option. Card pricing should capture the spread between processing cost and what merchants in the vertical will bear. ACH calls for a different commercial approach. B2B and high-ticket B2C merchants tend to accept a modest volume fee with a per-payment cap, rather than an identical treatment of both payment methods.

The source of pricing power is product depth. A platform that combines scheduling, invoicing, and payments can command more than a standalone processor because merchants assess the value of the software as a whole. Competitive processing rates are therefore not the only constraint. Payment method mix should also be designed deliberately, with merchant preference as one input. Card and digital wallets represent the dominant share of volume in benchmarked embedded payment portfolios, while ACH is significant in B2B and high-ticket verticals and grows as platforms make it easier to use.

How Pay Out — disbursements and embedded payables — extends the revenue model beyond acceptance

Acceptance captures only one direction of money movement. Platforms already embedded in invoicing and bill-pay workflows can also monetize outbound ACH, card, or check disbursements to vendors, contractors, and service providers. Embedded accounts payable automation keeps those economics inside the platform rather than conceding the workflow to a separate tool. The revenue opportunity also extends across receivables. B2B accounts receivable is one of the fastest-growing vertical payments segments, and frictionless card acceptance can unlock volume in a market where much payment activity still uses check or ACH.

A merchant using the same platform for incoming payments and outgoing disbursements depends on it for both AP and AR workflows. Leaving requires more than replacing a payment processor. It requires replacing the financial operating layer connected to the merchant’s work. Unified Pay In and Pay Out infrastructure therefore extends the chosen monetization model instead of creating a disconnected payment feature with separate economics.

How AI and agentic automation change what payment operations cost to run

AI-native infrastructure changes the cost of operating payments today. Automation can reduce the work required for merchant onboarding, risk monitoring, reconciliation, and dispute management. For vertical SaaS, the highest-value targets include progressive document collection, auto-approval routing, reconciliation, and disputes. These functions influence whether compliance costs grow linearly or sub-linearly with volume. As a result, the infrastructure partner’s automation capabilities affect how much of a stronger take rate survives as margin.

Agentic operations also impose concrete architectural requirements. They need clean APIs, unified payment metadata, explainable decision logs, and authority-level guardrails that prevent unintended transactions. Automation cannot be separated from those controls. An IMF note published in 2026 highlights the tension between probabilistic AI behavior and the deterministic requirements of payment infrastructure. Providers that resolve that tension in the architecture offer a more defensible operating model than those that treat controls as an afterthought.

Matching the right model to platform stage and ambition

The choice starts with what the platform can handle now, with the highest possible take rate a lower priority. An early-stage platform with low volume and limited payments engineering should use referral or fee-on-top markup to establish proof of concept and initial revenue. It should enter that arrangement with a defined volume trigger for graduation. With a meaningful merchant base and payments becoming a product expectation, PFaaS is the target model for most vertical SaaS businesses.

At scale, having people focused on risk and compliance makes full registration a sound next step. Roughly $50 million to $100 million in annual processing volume is the indicated crossover range, where recaptured provider margin can exceed the cost of running the infrastructure directly. Volume alone is not the complete decision. The platform also needs enough staff, a willingness to take on risk, and time to put the systems in place before it takes on those duties.

The infrastructure choice should preserve that path from the outset. A partner with unified Pay In, Pay Out, and Pay Ops that lets the platform move between models saves it from having to rebuild at each graduation. Investors have reason to examine that flexibility because appropriate ownership of payments supports higher revenue per customer, lower churn, and revenue whose growth is tied to customer volume independently of seat count. Those characteristics can compound at exit. Select the model that fits the platform now, and contract for the control and migration path its next stage will require.