ExpandUp Insights

The decisions that determine your payment program economics need to be made before your first vendor conversation. Here are the five that matter most — and what happens when you skip them.

BaaS works at $5M in monthly volume. It breaks at $50M. Here are the five structural reasons why — and what to do about them before scale makes them permanent.

The real economics of embedded payments — interchange, float, fee design, and why most SaaS platforms capture a fraction of available revenue. Written by operators who have done it.

The three primary embedded payments models compared by an operator who has run all of them. Economics, compliance, timeline, scaling limits, and what founders consistently get wrong.

Every AP company says they have a payment waterfall. Very few have true payment orchestration — automated exception handling, economics-aware routing, and a waterfall that doesn't stop when things go wrong.

Most programs treat speed as a cost. The programs generating real payments revenue treat it as a product. The spread between delivery cost and delivery value is margin — and most programs never capture it.

The bank keeps float revenue by default. Every BaaS program that didn't negotiate float economics in the bank relationship is giving away revenue it could be capturing from day one.

Workflow value, vendor graph monetization, settlement velocity pricing, embedded credit, and capital flow partnerships — the five levers that determine whether a payments platform is a revenue engine or a commodity.

Most platforms monetize transaction fees and interchange. The programs at the top of the revenue curve are also capturing network monetization, data products, and embedded working capital revenue simultaneously.

ERP connectors and API integrations are products — not implementation work. Every program builds them. Almost none charge for them. Here's the revenue model for turning integration into a recurring revenue line.

Programs with poor data models can't verify interchange rates, can't measure Level 2/3 data transmission, and can't reconcile FBO balances. They know total revenue but can't optimize it because they can't see it.

Structured remittance data eliminates manual reconciliation that costs more per transaction than the payment itself. Most programs give it away because their infrastructure can't carry it. That's a rail selection problem.

Some counterparties will never accept payment fees. The solution is to stop trying to monetize the payer — and start monetizing the receiver's problem instead. Three receiver-side revenue models that work.

Dynamic discounting turns early payment into a revenue product. The discount is the revenue. The working capital benefit is the value proposition. Most programs never get upstream enough in the AP workflow to offer either.

PayFac and BaaS/banking sponsorship have fundamentally different margin structures, compliance exposures, and flexibility ceilings. Most fintechs make this choice implicitly — by talking to a vendor first.

The decision to buy, build, or partner shapes cost structure, competitive differentiation, and flexibility for years. Most programs make it reactively. Here's the framework for making it deliberately.

ACH is the default. It's also the lowest-revenue, slowest, most data-constrained option available. A complete guide to multi-rail architecture: ACH, RTP, FedNow, Push-to-Debit, VCC, stablecoin, and eLockbox.

Three foundational components determine scale: ledger design, the orchestration layer, and the business rules engine. Programs that get all three right at launch scale cleanly. Deferring them is expensive.

ACH is deceptively simple. Return rate management, settlement model design, remittance format, and ODFI compliance all surface after launch for programs that didn't define them first.

"Bank-grade" appears in every BaaS pitch deck and is rarely defined. What a sponsor bank examination actually requires — BSA/AML, transaction monitoring, OFAC, KYC/KYB — is different from the marketing language.