Embedded finance and banking-as-a-service programs are middlemen by design. They buy financial infrastructure from a provider above, a sponsor bank, a BaaS platform, a processor, and sell it, embedded, to the clients below them, the brands and businesses putting cards, accounts, and payments in front of their own users. That in-between position is the entire business model, and it is also what makes billing structurally theirs to own. Unlike ordinary software billing, an embedded finance program's revenue is derived from transaction-level financial events under multi-party contracts, which makes it both more complex and more fragile. Embedded finance is among the fastest-growing categories in fintech, with forecasts placing the market in the hundreds of billions of dollars by 2030 and payments as its largest segment, so the number of programs facing this problem is rising quickly. This is how their billing works, and where it breaks.
TL;DR
- Embedded finance and BaaS programs sit between an upstream provider and downstream clients, so they both pay for infrastructure and bill for it, with markup, in the middle.
- Their client billing is built from transaction-level events under multi-party contracts, not flat subscription fees, which is what makes it complex.
- The components include program and platform fees, per-card and per-account fees, transaction fees, interchange revenue share, revenue-share splits, pass-through costs with markup, tiers, minimums, and true-ups.
- It breaks most often in interchange-share computation, revenue-share splits, pass-through markups, and the period-based charges that manual billing always drops.
- It is also a three-way reconciliation: what the program pays upstream, what it earns from activity, and what it bills or shares downstream all have to tie out, and the program is squeezed in the middle.
- The billing complexity cannot be outsourced, because it is inherent to being an intermediary. It is structurally the program's to own.
Short answer
Embedded finance programs bill their clients on charges derived from transaction-level activity rather than flat fees: program and platform fees, per-card and per-transaction charges, a share of interchange revenue, revenue-share splits defined in each client contract, pass-through costs with markup, plus tiers, minimums, and period-end true-ups. It breaks where that logic is hardest to compute and easiest to drop: interchange share, which depends on granular and variable transaction data; revenue-share calculations, which depend on the right split and base under the right contract version; and the period assessments that are not tied to any single transaction. Because the program both pays an upstream provider and bills downstream clients off the same activity, getting billing right is also a three-way reconciliation, and that complexity is inherent to the intermediary position rather than something that can be outsourced.
The structural position: paying up, billing down
To see why the billing is hard, start with where the program sits. Above it is an upstream provider: a sponsor bank that holds the regulatory permissions, a BaaS platform that supplies the rails, a processor that moves the card transactions. The program pays that provider for the infrastructure. Below it are the program's own clients: the brands, marketplaces, and businesses that embed the financial product into their offering and serve it to end users. The program bills those clients for the service.
That creates a three-way economic flow. Cost flows up to the provider. Revenue flows in from the activity itself, most notably interchange earned when end users transact. And billing, or revenue sharing, flows down to and from the clients. The program's margin is what is left after all three are reconciled against one another, and every one of the three is measured in transaction-level events rather than tidy monthly figures. The intermediary owns the hardest seat in the structure, because it is the only party that has to get all three sides right at once.
How embedded finance programs bill their clients
The downstream billing is assembled from several components, and the mix is where the complexity begins.
Program and platform fees. Recurring charges for running the program: a monthly platform fee, setup or onboarding fees, per-entity or per-program charges.
Per-unit fees. Charges that scale with the program's footprint: per active card, per account, per end user, per transaction.
Interchange revenue share. The most distinctive and most complex component. When end users transact, the program earns a share of interchange, and its contracts with clients often share some of that back, or bill against it. Computing each client's interchange position depends on transaction-level data that varies by card network, card type, merchant category, and region, which makes it the single hardest figure in the whole arrangement to get right.
Revenue-share splits. Many programs operate on explicit revenue-share arrangements, where a defined percentage of the economics flows to or from the client. The split, the base it applies to, and the contract version that governs it all have to be applied correctly per client per period.
Pass-through with markup. Upstream costs the program passes to clients, often with a margin added. The pass-through has to reconcile to the actual upstream cost, and the markup has to match the contract.
Tiers, minimums, and true-ups. The same conditional logic that governs any usage-based contract: pricing that steps with volume, minimum monthly fees with their true-ups, and period-end adjustments, all of which have to be assessed against the closed period.
Where it breaks
Because the billing is transaction-derived and multi-party, it breaks in specific, predictable places.
Interchange share. This is where the most errors hide, because interchange itself is granular and variable, and a client's share has to be reconstructed from the underlying transactions rather than read off a summary. A small error in how interchange is attributed, multiplied across every transaction, becomes a material mis-share that either shorts the client, inviting a dispute, or shorts the program, quietly eroding margin.
Revenue-share calculations. Applying the wrong split, the wrong base, or a superseded contract version produces a revenue-share figure that is confidently wrong. Across a portfolio of clients on different splits, this is a steady source of both over- and under-payment.
Pass-through markups. When the upstream cost the program is passing on does not reconcile to what the client is billed, the markup drifts from the contract, in one direction or the other, and neither party notices until someone checks.
Period assessments. Minimums, platform fees, and true-ups are not triggered by any single transaction, so a manual process has to remember to assess the closed period and raise them. They are the first thing dropped under pressure, which means uninvoiced revenue for the program and surprise charges for the client.
Contract versioning. With many client programs each on its own terms, and amendments landing mid-period, applying the current contract to a whole period rates some activity under terms that were not in force, the same versioning seam that breaks billing everywhere, multiplied by the number of programs.
The three-way reconciliation
What makes the embedded finance case distinct from ordinary client billing is that getting the downstream invoice right is not enough on its own. The program also has to reconcile what it pays the upstream provider and what it earns from activity against what it bills and shares downstream, because its margin is the residual of all three. If the upstream cost is wrong, the program overpays. If the interchange or activity data is wrong, the revenue is misstated. If the downstream billing or share is wrong, the client relationship and the margin both suffer. The three sides are computed from the same underlying transactions, so an error in the data propagates into all of them at once. The intermediary cannot get billing right while ignoring the other two sides, because they are the same problem viewed from different ends.
Why this is structurally the program's to own
It is tempting to think of billing as back-office plumbing that could be handed off. For an embedded finance program it cannot, because the billing logic is the business. Being an intermediary means the program's entire economics are defined by the relationship between what it buys and what it sells, and that relationship is expressed in the billing. The complexity is not incidental; it is the direct consequence of sitting between a provider and a set of clients and earning the spread. And because the charges are derived from transaction-level events rather than flat fees, the program inherits every conditional-logic and period-assessment problem of usage-based billing, plus the interchange and revenue-share complexity that ordinary software businesses never face.
That position also means the program is simultaneously a payables problem and a receivables problem. It needs to verify that its upstream provider charged it correctly, the same provider-economics question any cross-border platform faces, and it needs to bill and share with its downstream clients correctly. Both run off the same transaction events, which is why the cleanest answer is to drive both from one record of those events rather than two disconnected processes. That single-source approach to both sides is what platforms such as Bluefyn are built around, and it fits the embedded finance program almost exactly, because the program is the textbook case of a business squeezed in the middle of two contracts at once. Bluefyn analyzes transaction and provider data; it never moves, holds, or custodies funds.
The bottom line
Embedded finance and BaaS programs own a billing problem that is structurally harder than most software businesses ever encounter, because their revenue is derived from transaction-level events, governed by multi-party contracts, and earned by sitting between a provider and a set of clients. It breaks where that logic is hardest, in interchange share, revenue splits, pass-through markups, and the period assessments manual processes forget, and it is complicated further by being a three-way reconciliation rather than a one-way invoice. None of it can be outsourced, because the billing logic is the business model. The programs that scale cleanly are the ones that treat both sides, what they pay upstream and what they bill downstream, as one problem driven by the same events.
Frequently asked questions
How do embedded finance programs bill their clients?
They bill on charges derived from transaction-level activity: program and platform fees, per-card and per-account and per-transaction fees, a share of interchange revenue, revenue-share splits defined in each client contract, pass-through costs with markup, and conditional charges like tiers, minimums, and period-end true-ups. The mix and the transaction-level derivation are what make it complex.
What is interchange revenue share in embedded finance?
It is the arrangement by which a program earns a share of the interchange generated when end users transact, and shares some of that with, or bills it against, its clients. Computing each client's interchange position requires reconstructing it from transaction-level data that varies by network, card type, merchant category, and region, which makes it the hardest figure to get right.
Why is embedded finance billing harder than normal SaaS billing?
Because it is derived from transaction-level financial events under multi-party contracts rather than flat subscription fees. The program inherits every conditional-logic and period-assessment challenge of usage-based billing, and adds interchange and revenue-share complexity that ordinary software businesses never deal with.
Where does embedded finance billing break most often?
In interchange-share computation, revenue-share calculations, pass-through markups, and period assessments like minimums and true-ups. Contract versioning across many client programs adds further error, as activity gets rated under terms that were not in force when it occurred.
Why is billing structurally the program's responsibility?
Because the billing logic is the business model. An embedded finance program's economics are defined by the relationship between what it buys upstream and what it sells downstream, and that relationship is expressed in the billing. The complexity is inherent to being an intermediary and cannot be outsourced away.
Is embedded finance billing a payables or a receivables problem?
Both. The program must verify that its upstream provider charged it correctly, a payables and provider-economics question, and bill or share with its downstream clients correctly, a receivables question. Both are computed from the same transaction events, so they are most reliably handled as one problem driven by a single record of those events.
