If your platform currently just redirects users to an external checkout page to pay, then you're losing revenue to third parties and loosing customers at the point of checkout.
The alternative? Building payments (and payouts, card issuance, or BNPL) natively into your own product instead. And no, you don't have to become a bank to do that.
Embedded finance means shipping a financial product (payments, card issuance, payouts, BNPL) as a native part of your own product, instead of redirecting users to a third party.
The interesting part for us as builders isn't the fintech marketing angle, but that the architecture is a real distributed-systems problem: three parties, three ledgers, one experience that has to feel instant and atomic to the end user.
The payment stack, broken down
Here are the three layers that have to work together to bring embedded payments to your platform.
- Sponsor bank — holds the actual banking charter. Direct member of Visa/Mastercard and the ACH/Fedwire/RTP rails. Sets KYC/AML rules everyone downstream inherits. Carries primary regulatory liability.
- BaaS provider — the API layer. Card issuance, KYC tooling, ledgering, webhooks — the actual SDK/API surface you integrate against.
- End-brand (you) — owns the UI, the customer relationship, and data handling, but never touches the license or the compliance rulebook directly.
_In practice: Lyft Direct's driver payout flow is Stride Bank (license) + Payfare (API/infra) + Lyft (product surface). When a driver cashes out, that's Payfare's API calling into Stride Bank's ledger over ACH/RTP, settling in what feels like a single request from the app's perspective but is actually a handoff across three separate systems of record.
_
The build-vs-integrate tradeoff, technically
Building this yourself is a lot of work. But it isn't a payments-API problem, it's a licensing and reconciliation problem:
You'd need a chartered bank partner or your own license, continuous KYC/AML monitoring infrastructure, and direct rails integration — none of which is a weekend SDK install.
Reconciliation across independently-ledgered systems is hard. Synapse's 2024 collapse — a BaaS middleware failure that triggered a multi-party dispute over tens of millions in customer funds — happened specifically because there was no shared source of truth across the bank, the middleware, and the fintechs on top of it.
Regulatory scrutiny lands on your sponsor bank, not you directly — but if your bank partner gets hit with an enforcement action (over a quarter of FDIC actions in 2024 targeted sponsor banks in embedded finance deals), your product can go down anyway. Vetting your provider's stability matters as much as their API docs.
TL;DR: Using a provider means you're integrating against a defined API contract instead of owning the ledger reconciliation and compliance surface yourself.
What that integration looks like for real platforms
- Cal.com replaced an external checkout redirect with native in-app payment across card, ACH, wire, and crypto
- Nickel consolidated a split setup (cards on one processor, ACH/payouts on a separate banking partner) into a single API, and saw card checkout completion go from 11% to 17%.
- FoodFluence built a payout portal on top of a provider's payout API instead of stitching together billing, bank transfers, and a separate payout vendor manually.
Read the full breakdown
The full post goes deeper on the three-layer model, the Synapse failure mode in more detail, and a rundown of what to actually evaluate in a provider's API/compliance surface (Whop, Stripe, Adyen for Platforms, Marqeta, Unit): What is embedded finance? A complete guide for platforms
Top comments (0)