Pay in Pay Out Pay Ops Frameworks Compared

A vertical SaaS platform can have "payments" live inside its product and still be losing most of the money payments were supposed to generate. A merchant signs up, processes a card transaction inside the software, and the platform collects a cut. But that same merchant pays its vendors through a separate bank portal the platform never sees, its onboarding has been sitting in a manual review queue for days, and nobody on the product team can say how much outbound volume moves through its customer base every month. That is what happens when a platform treats payments as one feature instead of three distinct layers, each with its own mechanics, revenue logic, and compliance surface. The consequence is predictable: attach rates stall at a fraction of eligible merchants, interchange revenue on the outbound side goes uncaptured, and compliance gaps stay invisible until a card network audit or a fraud event forces them into view. Pay In (acceptance), Pay Out (disbursements), and Pay Ops (onboarding, risk, and operations) give platforms a way to reason about each of those problems on its own terms before deciding how to bring them together. The stakes for getting this right are rising, too: agentic systems are already routing around entire SaaS application layers to transact directly, and transaction-driven revenue from embedded payments is turning into a structural requirement for SaaS economics and a growth lever.

How the monetization model at the Pay In layer determines payment revenue

The single decision shaping whether embedded payments becomes a real revenue line or a rounding error has nothing to do with pricing or transaction volume. It's which monetization model a platform runs at the Pay In layer. Four models sit on a ladder of increasing control and increasing revenue, and most platforms never climb past the bottom rung.

At the bottom sits the referral or ISO model, where a platform simply points merchants toward a processor and collects a small residual for the introduction. This model once dominated payment processing, but it has fallen sharply as embedded alternatives have displaced it, because a referral fee caps out at whatever the processor decides to share. One step up is the integrated or fee-on-top markup model, where the platform sets a price above its own processing cost and keeps the spread. That produces more revenue than a pure referral, but the platform still has no real control over pricing flexibility, the merchant experience, or the transaction data flowing through it. The model that changes the economics entirely is PayFac-as-a-Service, or PFaaS, which gives a platform the control and the margin of a registered payment facilitator without requiring it to take on the registration itself. On identical volume, a genuine PFaaS deal can bring in five to ten times what a referral arrangement brings in.

That gap is large enough that it should change how a platform vets any provider pitching itself as PFaaS. Two questions separate the real thing from a relabeled referral deal: Is this a true processing-margin revenue share, or a fixed referral fee dressed up in different language? And can the platform set merchant pricing above the provider's cost and keep that spread? Some providers marketed as PFaaS turn out, on close inspection, to be structurally closer to the referral model they claim to replace.

Infrastructure built to treat payment acceptance, disbursements, and operations as one interdependent system, such as Payabli's unified Pay In, Pay Out, and Pay Ops platform, makes these trade-offs visible in the term sheet itself. A platform that can see how its acceptance model interacts with its disbursement economics and its onboarding flow is in a far better position to negotiate, or to build, the right arrangement.

None of this matters, though, if attach rate stays low. Most platforms stall at a small fraction of eligible merchants actually processing on-platform, and that low attach rate amplifies or erases whatever monetization model sits underneath it. Moving attach rate from low to high across a mid-sized merchant base can add millions in monthly gross payment volume without signing a single new customer. Toast's payments revenue now exceeds its subscription revenue by more than five times, a ratio drawn straight from its own financial filings, and the same structural logic scales down to platforms a fraction of its size. A16z's research backs this up from a different angle: incorporating financial products into a vertical SaaS offering can increase revenue per user by two to five times while holding customer acquisition cost flat or lower, because the financial product sells into a customer base the platform already has. Attach rate is where all of that potential either gets captured or gets left on the table, which is exactly the problem Pay Ops exists to solve.

Pay In: rails and acceptance channels

Once the monetization model is settled, Pay In becomes a question of infrastructure: which rails a platform supports, and how it orchestrates across them. Five rails make up the core of a modern B2B payments architecture: ACH, wire, the instant rails RTP and FedNow, commercial cards, and, in narrower cross-border cases, stablecoins. Each carries its own cost structure, settlement speed, finality rules, and compliance requirements, and a platform that picks one rail by default is making a decision that will constrain it later.

ACH remains the volume backbone of B2B payments, and ACH, same-day ACH, RTP, and FedNow are the rails most embedded bank payment products are built to support. Instant rails have crossed a real threshold, and they are no longer a niche option. RTP has raised its per-transaction limit, so it now carries genuine corporate volume. FedNow settles in central bank money and has expanded to a large and growing number of financial institutions across the country, and its transaction limit was raised from $1 million to $10 million effective November 12, 2025, matching the $10 million limit RTP adopted in February 2025.

Every instant rail shares one property, and it is the one payment teams most often underestimate: finality. Once a payment settles on RTP or FedNow, it is done. There is no card-network chargeback process sitting behind it to unwind a mistake or a fraudulent transaction after the fact. That means fraud controls have to be validated before a payment leaves, not after, and any platform treating instant rails like cards with faster settlement is building on a false assumption. This same constraint resurfaces on the outbound side, where the cost of getting it wrong is identical.

Multi-rail orchestration is the only architecture that holds up under this complexity. A well-run acceptance layer routes across card networks, ACH, instant rails, wire, and selectively stablecoins, and most platforms need at least three of the five active at once to serve their merchant base without friction. Every rail a platform adds widens acceptance coverage and cuts friction for merchants, but it also adds integration surface, compliance scope, and reconciliation work. A unified infrastructure partner that absorbs that complexity tends to outperform a patchwork of point integrations.

One distinction gets missed constantly in how platforms design this layer: the rail that pulled the buyer's money is rarely the rail that pays the seller. Pay-in rails and pay-out rails are chosen separately, for different reasons, against different constraints, and conflating them is a design error that stays hidden until volume exposes it. That's the seam where Pay In ends and Pay Out begins.

Pay Out: embedded payables, AP automation, and outbound revenue

Pay Out, the disbursement layer, runs on its own rails, carries its own compliance requirements, and is a distinct revenue stream that most platforms focused on acceptance overlook almost entirely. Embedded payables let a vertical SaaS platform run automated vendor payouts from inside its own product. The platform can then earn on the money its customers send out, not only on the money it collects on their behalf.

Historically, that outbound money has moved through paper checks, manual ACH batches, or third-party AP tools, none of which the platform owns and none of which it monetizes. That is changing because B2B ACH volume on the outbound side has grown substantially year over year as businesses move away from paper checks, and embedded payables infrastructure is built to capture that growth. Accounts payable automation itself has shifted from a back-office efficiency project into a strategic priority, with invoice processing, approval workflows, vendor enablement, and payment disbursement converging into a single platform layer.

Emburse's launch of Emburse AP on September 16, 2026 shows how fast this convergence is arriving in the market. The product combines AI-powered invoice processing, approval workflows, vendor enablement, and payments in one platform, with embedded global payment rails powered by licensed financial services partners, including REPAY. It's a useful marker of where the category is heading: unified AP and payments as a single product decision, not two separate vendor relationships bolted together after the fact.

On the developer side, embedded payout APIs let a SaaS company send money to contractors, sellers, or platform users with a few lines of code, while the API itself handles verifying payee identities, routing funds across ACH, RTP, mobile money, or digital wallets, filing the associated tax forms, and keeping a transaction history. The revenue models available here are varied: platforms can charge for instant payout access, earn FX spread on cross-border disbursements, or capture float yield on settlement balances held pending disbursement.

There is no reversal mechanism once a payout rail executes, so fraud and identity controls have to sit upstream of execution rather than downstream of it, just as irrevocability shapes controls on the Pay In side. Verifying who a payee actually is, before money moves, separates a Pay Out layer that generates revenue from one that generates liability.

Pay Ops: merchant onboarding, KYB, and risk monitoring

Pay Ops, the work of merchant onboarding, know-your-business (KYB) checks, risk scoring, and ongoing monitoring, is where most platforms underinvest until something goes wrong. Its quality sets the ceiling on how fast Pay In and Pay Out can actually grow, because neither layer functions at scale without it.

The chain runs in one direction. Onboarding is the operational bottleneck that determines attach rate. If setting up payments is a separate conversation, with a separate vendor, after a merchant has already gone live on the platform, most merchants never finish it, and the low attach rate described earlier in the Pay In discussion persists. Manual KYB review averages multiple days per merchant, but automated KYB compresses that time sharply, raising both attach rate and time-to-first-transaction. If a merchant completes onboarding in minutes instead of days, it starts generating revenue sooner, so a platform with a high completion rate can capture GPV a slower competitor simply cannot.

A tiered approach to risk scoring is what makes this speed possible without abandoning diligence. If a merchant comes in low-risk, with clean data, it gets auto-approved. Medium-risk merchants get flagged for expedited manual review. High-risk merchants go through enhanced due diligence. The factors scored at onboarding, business age, merchant category code, projected volume, ownership complexity, and geographic risk, let a platform route the bulk of its merchants through quickly while reserving its compliance resources for the smaller set that actually needs them.

Onboarding is only the first checkpoint. A merchant that looked clean at signup can change ownership, pivot into a prohibited product category, or develop a transaction pattern that looks nothing like what it reported initially, and without continuous monitoring, none of that gets caught until a card network audit, a fraud event, or a regulatory exam forces it into view. The compliance obligations themselves, identity and business verification checks, sanctions screening, fraud detection, and transaction monitoring, aren't optional extras a platform can skip. Sponsor banks, card networks, and federal law require them. The only real choice a platform has is whether it builds the capability to handle them directly or works with a partner that absorbs the obligation on its behalf. That choice marks one of the most consequential operational differences between the two Pay In models discussed earlier: under PFaaS, the partner absorbs the regulated back-end functions, while a full PayFac registration means the platform owns them permanently.

Artificial intelligence is starting to reshape this layer specifically. Agentic AI systems that can execute multi-step financial workflows on their own are among the fastest-growing categories in financial services, even though most deployments are still in early or pilot stages, and vendors are targeting onboarding and ongoing monitoring as two of the primary use cases first.

How AI and agentic automation are changing all three layers

AI is becoming the operating layer through which Pay In, Pay Out, and Pay Ops functions actually get executed, and platforms that treat it as an add-on rather than a foundation will fall behind in ways that compound over time.

Autopay and rules-based automation have existed for decades, but agentic AI represents a different category of capability: systems that make decisions and take actions to achieve a goal a user has defined. So transactions can be initiated, managed, and carried out by adaptive systems acting with delegated authority, not just triggered by a static condition someone configured months earlier. Adoption across financial services is moving quickly, with agentic systems that run multi-step financial workflows autonomously counted among the fastest-growing categories in the industry.

Production deployments are no longer hypothetical. Visa and Mastercard are both deploying multi-agent systems for agent-initiated commerce, and JPMorgan Chase is deploying AI agents inside its wealth management business. These are large, regulated financial institutions putting autonomous decision-making into live transaction flows, which is a signal of how fast the ground is shifting under every layer of this framework.

On the Pay In side, agentic systems can select the best available rail for a given transaction in real time, detect and route around failures, and trigger retries automatically, pulling manual oversight out of routine acceptance decisions that used to require a human to intervene. On the Pay Out side, agentic AP automation can handle invoice ingestion, approval routing, payee verification, and disbursement execution from end to end, and the Emburse AP launch ships that convergence as a live product.

If you integrate a multi-rail Pay In layer with Pay Out and Pay Ops on one platform, your product team can see which rails and which acceptance channels drive the highest-margin volume and which merchant cohorts gravitate toward which payment paths. That visibility feeds directly into pricing decisions and feature prioritization, and it's the kind of data a platform simply doesn't have when its three payment layers live in three disconnected systems. As agentic AI takes on more of the execution work across acceptance, disbursement, and onboarding, the platforms positioned to benefit will be the ones whose infrastructure was built from the start to treat these three layers as one connected system, not the ones trying to stitch autonomous decision-making onto a patchwork assembled one vendor at a time.