In a marketplace, one buyer payment ends up in two places: the platform's commission and the seller's balance. Between checkout and payout, some entity holds that money on its own books. Which entity holds it, and under whose authorization, is the decision that sets counterparty risk for every seller on the platform.
What is a split payment?
A split payment is a single payment from a buyer that is divided, at the moment it settles, between two or more recipients. In a marketplace, the usual division is the platform's commission on one side and the seller's net amount on the other. The buyer sees one charge. The ledger behind it records two or more destinations.
The mechanics are well understood by now. A platform sends the payment instruction with the split rule attached, the commission is retained automatically, and the remainder is credited to the seller. Providers differ on something else: where the seller's share sits, and for how long, before it reaches the seller.
Every split has a holder of record
Between the moment a buyer pays and the moment a seller is paid, the money exists somewhere. It sits in an account, on the books of a licensed institution, in the name of a holder of record. That holder is a legal fact, not a display choice in a dashboard.
Marketplaces routinely run payout cycles of a few days: time to confirm delivery, to run a refund window, to settle chargebacks. During that window, seller money is on someone's balance sheet. If the platform never decided whose, the answer was decided by the payment stack it bought.
Who holds seller funds before payout?
In practice the market resolves this in two ways, and they are worth naming as categories rather than as vendors.
In the aggregation model, the platform or its provider collects buyer payments into a single pooled account it controls, keeps an internal ledger of what each seller is owed, and pays out from that pool. The seller has a balance in a system. What the seller does not have is an account in its own name at a licensed institution. The obligation is a claim against the operator of the pool.
In the licensed layer model, each seller is the holder of record of a local account in its own name, opened and operated under a regulated framework, and the split credits that account directly. The platform still sets the commission rule, still controls the payout schedule, and still owns the experience. What changes is that the seller's balance is the seller's, held by a licensed entity, rather than a line item inside the platform's pooled balance.
Both models are used at scale. Both are legitimate. They price risk differently, and only one of them is a choice a platform can make after the fact without migrating every seller.
What breaks when the holder is a third party
The exposure in the aggregation model is credit risk, and it is usually invisible until it is not. If the operator of the pooled account fails, is suspended, or freezes settlement, seller balances are inside that failure. Sellers do not have an account elsewhere to fall back on, because the account they thought they had was a ledger entry.
Platforms tend to evaluate payment providers on take rate, approval rate and integration effort. Counterparty exposure to the entity holding the float rarely appears on that list, even though it is the only item that can take the whole seller base down at once.
The second effect is quieter. In the aggregation model the platform inherits an operational duty it did not ask for: it becomes the place sellers go when money is late, because it is the only party with visibility into the pool. That duty scales with the seller count, and it does not scale with the payments team.
What does this change for reconciliation?
It changes what reconciliation can match on. When each seller holds an account in its own name, every credit carries an identifier that belongs to that seller and every payout carries a reference the seller can see on its own statement. Matching is between two records of the same event.
When the balance lives in a pool, reconciliation is between the platform's internal ledger and the provider's internal ledger, and the seller has no third record to check against. Disputes become a support conversation instead of a lookup. Month-end closes take longer for the same reason: the truth is reconstructed rather than read.
There is a related question about how the money leaves the platform once the split is done. Payout rails differ by market and by day of the week, and a split that credits correctly can still miss a payout window. That is a separate decision from custody, and it is covered in our note on seven questions before choosing cross-border infrastructure.
Four questions before choosing the model
These are the questions that surface the architecture, and they are all answerable in a first conversation with a provider.
- Whose name is on the account that holds seller funds between checkout and payout? If the answer describes a balance in a system rather than a holder of record, the model is aggregation.
- Which licensed entity operates that account, in the market where the seller is? Local rails are operated by locally authorized participants, and the arrangement behind an offer is a fair thing to ask about. What can be embedded and what requires a license is set out in our note on what you can embed, and what needs a license.
- If the intermediary stops settling tomorrow, what does the seller hold? An account, or a claim.
- What record does the seller get, independent of the platform? A statement the seller can read without asking the platform is the difference between a lookup and a support ticket.
None of these questions require a lawyer to ask. They do require the platform to have an answer before the first thousand sellers are onboarded, because after that the answer is a migration.
Where this lands for a marketplace operating across borders
In 2026, a marketplace collecting in Brazil, Mexico or Colombia and paying sellers in those same markets is making this decision three times, once per market, with a different set of local rails each time. The structure that keeps it consistent is one integration for collection, split and payout, with the licensed layer operating underneath in each country.
That is the arrangement we run for marketplaces: commission retained automatically at the moment of the split, sellers paid in local currency on the local rail of their market, and the seller as the holder of record of the account that receives it. Collection and disbursement sit on the same integration, through Pay-In and payout, on one ledger.
The split is the visible part. The holder of record is the part that decides what happens on a bad day.
What is a split payment in a marketplace?
A split payment is one payment from a buyer that is divided at settlement between the platform's commission and one or more sellers. The buyer is charged once. The platform sets the split rule, and the commission is retained automatically rather than invoiced back to the seller later.
Who holds the seller's money between checkout and payout?
Either a pooled account controlled by the platform's provider, in which case the seller holds a claim against that operator, or an account in the seller's own name at a licensed institution, in which case the seller holds the balance. Both models exist at scale. The difference only becomes visible when the intermediary fails.
Can a foreign marketplace split payments to sellers in Latin America?
Yes. The collection, the split and the payout can run on one integration, with locally authorized entities operating the accounts and the rails in each market. The platform sets the commercial rules and the payout schedule.
Does split payment change how a marketplace reconciles?
It changes what reconciliation matches on. When sellers hold accounts in their own name, each credit and each payout carries an identifier both sides can read, and matching is record against record. When balances sit in a pool, the seller has no independent record, and month-end reconstruction replaces lookup.