Refund after payout
The buyer is refunded after the seller was paid. The platform carries the loss unless a reserve or negative balance was modelled.
Marketplaces
One buyer payment can owe money to five parties.
A marketplace order splits into seller proceeds, platform commission, fees, reserves and sometimes taxes, then changes again on refund or dispute. Orangepill records each of those obligations in one ledger, so every seller balance and every payout can be traced back to the order behind it.
The problem
Settlement logic grows faster than the marketplace.
The first version pays sellers weekly from a spreadsheet. Then come commission tiers, rolling reserves, partial refunds, chargebacks after payout and sellers in more than one currency. Each rule is added where it was needed, and soon nobody can say with confidence what a seller is owed today.
Typical architecture today
Order data, payment data and payout data in three places.
- Order system Items, sellers, prices
- Payment provider Buyer charge
- Payout job Computes what sellers are owed
- Payout provider Sends seller funds
- Finance spreadsheet Explains the difference
Where it breaks
Most marketplace incidents are timing problems.
Commission recalculated
A pricing change is applied retroactively by a batch job, and seller balances no longer match past statements.
Hold never released
An order is held for delivery confirmation, the confirmation arrives through a different system, and the seller waits.
Payout retried blindly
A seller payout times out, the job reruns, and the seller is paid twice from the platform's own funds.
Orangepill model
A seller balance is the sum of what happened to their orders.
Every split, hold, commission, reserve and refund is a ledger event tied to an order. Seller balances, platform revenue and reserve positions are derived from those events. A payout draws down a balance that already reflects every obligation against it, so the payout job stops being the place where settlement is decided.
Example workflow
The lifecycle of one marketplace order.
- Buyer pays Pay-in confirmed by provider
- Split recorded Seller share, commission, fees
- Held Until delivery or release policy
- Released Reserve retained; rest available
- Seller payout Executed and verified
If the buyer is refunded before release
The held entries are reversed. The seller never sees funds they would have had to return.
If a dispute arrives after payout
The amount is recovered from the seller's reserve or future balance under your policy, and recorded against the original order.
Capabilities used
The parts of the runtime a marketplace leans on.
Wallet & Ledger
One ledger for buyer funds, seller balances, platform commission and reserves. Every split is a set of entries, not a calculation repeated in code.
Explore Wallet & Ledger →Execution
Pay-ins, refunds and seller payouts run as governed lifecycles, each linked back to the order that caused them.
Explore Execution →Multi-Rail Orchestration
Collects through one set of providers and pays sellers through another, without the seller ledger caring which.
Explore Multi-Rail Orchestration →Proof of Record
Answers the seller who asks why a payout was smaller than expected, with the events that produced it.
Explore Proof of Record →Outcome
Seller statements that hold up to questions.
- Change commission or reserve rules without rewriting the payout job.
- Pay sellers from balances that already account for holds and refunds.
- Reconcile provider settlement against the ledger instead of a spreadsheet.
- Answer seller payout questions from recorded events, not reconstruction.
- Add a payout method or a selling region without changing settlement logic.
Walk us through one order, from checkout to seller payout.
We will map your splits, holds, reserves and refunds onto ledger events and show where your current settlement logic can drift.