Short answer
A payment facilitator earns a spread. It is charged one rate by its provider, the buy rate, and it bills its sub-merchants a higher rate, the sell rate, and it lives on the difference. That margin is thin, and it is only as real as your ability to check both sides. If the provider overcharges the buy side, or the sub-merchant billing misfires on the sell side, the spread you thought you earned is not the spread you kept. Four leaks are specific to the payment facilitator model, and each one erodes the margin quietly, from a side most reconciliation never checks. Catching them means verifying both sides of the spread against the contracts that set them.
The spread a payment facilitator lives on
Start with the model, because the risk follows directly from it. A payment facilitator sits between an acquirer or processor and a set of sub-merchants it onboards under its own master account. On one side, the provider charges the facilitator for processing. On the other, the facilitator sets the price its sub-merchants pay. The facilitator's revenue is the gap between the two, which is the heart of its provider economics.
Illustrative numbers make the shape clear, and they are illustrative rather than a real rate. Say the provider charges the facilitator an effective 2.5 percent, and the facilitator bills its sub-merchants 3.2 percent. The 0.7 percent in between is the business. Every basis point of it matters, because the facilitator carries the cost, the risk, and the operations, and 0.7 percent is what pays for all of it.
That is the point worth holding onto. A payment facilitator does not have a comfortable margin it can afford to leave unchecked. It has a spread, and the spread is the whole enterprise.
The spread is only as real as your verification
A facilitator has two fee surfaces, not one. The buy side is what the provider charges it. The sell side is what it charges sub-merchants. Most fee checking, where it happens at all, looks at one side. The facilitator's economics depend on both.
On the buy side, a facilitator is a customer like any other, and its provider charges are exactly as prone to a rate deviation, a duplicate fee, or a markup as any merchant's. On the sell side, the facilitator is the biller, and its own sub-merchant invoices can misprice, misclassify, or mistime a charge. An error on either side moves the same spread. A provider overcharge on the buy side narrows it from below. A sell-side billing error narrows it from above, or exposes the facilitator to a sub-merchant dispute that claws revenue back later.
So the honest statement of the margin is conditional. The spread is 0.7 percent only if the buy side was charged correctly and the sell side was billed correctly, on every transaction. Verifying both, per transaction, against the two contracts that govern them, is what turns the spread on paper into the spread in the bank.
The four leaks specific to the model
Some fee problems are universal. These four are shaped by the payment facilitator model itself, and they are the ones a general reconciliation tends to miss.
Buy-rate and sell-rate tier misapplication
A facilitator's pricing is tiered on both sides. The provider prices the facilitator by volume band, card type, and transaction profile. The facilitator prices sub-merchants the same way. The leak is a transaction that lands in the wrong tier on either side: a buy-side charge computed at a higher band than the facilitator's volume earns, or a sub-merchant billed under a costlier category than its profile should carry. The margin assumes each transaction sits in the tier the contract specifies. When the tier is misapplied, the spread on that transaction is not what the model predicts, and the error repeats across every transaction of the same profile.
Interchange pass-through errors
Much of what a provider charges a facilitator is interchange, passed through from the card networks. Interchange is not one number. It is hundreds of categories, and the category a transaction qualifies for depends on how it was processed. The leak is a transaction that was charged a more expensive interchange category than it qualified for, passed straight through to the facilitator and, often, straight on to the sub-merchant. Because it looks like a legitimate network cost, it survives a reconciliation that confirms the provider's math without checking whether the transaction qualified for a cheaper category in the first place.
Funding and settlement timing gaps
A facilitator funds its sub-merchants on one schedule and is settled by its provider on another. Fees are taken at different moments across that gap: some netted at settlement, some billed monthly, some deducted from sub-merchant funding. The leak is a fee applied in the wrong window, or a charge that lands after the terms that priced it changed, or a funding timing that quietly shifts the facilitator's working capital. A check that compares a monthly total to a monthly total cannot see it, because the error is in when the charge hit, not in the sum at month end.
Chargeback and reserve liability
A facilitator is liable for its sub-merchants. When a sub-merchant takes a chargeback and cannot cover it, the facilitator absorbs it, along with the associated fees. Providers also hold reserves against that risk, and the terms governing those reserves and the fees on disputes are their own fine print. The leak is a chargeback fee charged above the contracted amount, a reserve held longer or larger than the terms allow, or a dispute cost misattributed. These sit outside ordinary fee reconciliation entirely, and they land directly on the facilitator's own margin.
The leak points at a glance
| Leak | Which side | How it erodes the spread |
|---|---|---|
| Tier misapplication | Buy and sell | A transaction priced in a costlier band than its contract specifies, repeated across its whole profile |
| Interchange pass-through | Buy | A transaction charged a more expensive interchange category than it qualified for, passed through as a legitimate cost |
| Settlement timing | Buy | A fee applied in the wrong window, invisible to a month-end total comparison |
| Chargeback and reserve | Buy | Dispute fees above contract, or reserves held beyond the terms, landing straight on the margin |
How a payment facilitator is different from an embedded finance program
The two models rhyme, and they are not the same. An embedded finance or banking-as-a-service program embeds financial products into a non-financial platform, and its billing problem is broad. A payment facilitator is the narrower, payments-specific case: it aggregates sub-merchants under a master processing account and lives on the buy-rate to sell-rate spread. The general form of paying up and billing down, and where that breaks, is covered in how embedded finance programs bill their clients. The payment facilitator is the specific version: a thinner spread, two fee surfaces, and four leaks that come from the model itself.
Verifying both sides
The method is the same on both surfaces, and it is the one a facilitator's margin requires. Reconstruct the expected charge for every transaction from the contract that governs it, the provider contract on the buy side and the sub-merchant agreement on the sell side, and compare it to what was actually charged or billed. Read the gap. A facilitator that does this sees its true spread per transaction, catches a tier misapplication or an interchange error while it is still one transaction rather than a quarter of them, and holds its providers and its own billing to the terms both agreed to.
That is the job Bluefyn is built for. Bluefyn reconstructs each contract into an expected charge for every transaction and compares it to what was actually charged, on the provider side and the billing side, so a facilitator can see where the spread leaks and flag it. It analyzes transaction and provider data. It never moves, holds, or custodies funds. It does not fund your sub-merchants or take your fees. It verifies that the fees taken and billed match the contracts that set them, which is what keeps the spread you earned.
Frequently asked questions
How does a payment facilitator make money?
On a spread. The provider charges the facilitator a buy rate for processing, and the facilitator charges its sub-merchants a higher sell rate. The difference, often a fraction of a percent, is the facilitator's revenue, and it pays for the facilitator's cost, risk, and operations. Because the spread is thin, small fee errors on either side, the provider charges coming in or the sub-merchant bills going out, move the margin meaningfully.
What is the difference between a payment facilitator and an embedded finance program?
A payment facilitator is a payments-specific model: it onboards sub-merchants under its own master processing account and earns the spread between its buy rate and its sell rate. An embedded finance or banking-as-a-service program is broader, embedding financial products such as accounts, cards, or lending into a non-financial platform. The facilitator's fee economics are narrower and thinner, which is why verifying both the buy side and the sell side per transaction matters so much to it.
Why does a payment facilitator need to verify fees on both sides?
Because its margin is the gap between the two sides, and an error on either one moves that gap. A provider overcharge on the buy side narrows the spread from below. A sub-merchant billing error on the sell side narrows it from above or invites a dispute that claws revenue back later. Checking only one side leaves the other free to erode the margin unseen. The spread is only real if both sides were charged and billed as the contracts specify.
What fee leaks are specific to the payment facilitator model?
Four. Tier misapplication, where a transaction is priced in a costlier band than its contract specifies on the buy or sell side. Interchange pass-through errors, where a transaction is charged a more expensive interchange category than it qualified for. Settlement timing gaps, where a fee is applied in the wrong window and a month-end total cannot see it. And chargeback and reserve liability, where dispute fees or held reserves exceed the contracted terms and land directly on the facilitator's margin.
Can a payment facilitator verify sub-merchant fees automatically?
Yes, and at any real volume it has to. The method is a per-transaction comparison of the actual charge against the expected charge reconstructed from the contract, run on both the provider side and the sub-merchant side. By hand it works for a small book and teaches the patterns. Past a few thousand transactions a month a manual check can only sample, and the errors outside the sample keep eroding the spread. An automated comparison checks every transaction on both surfaces, which is the only way to hold a thin margin to the terms that define it.
