Map every participant and responsibility
Start with obligations, not screens. A marketplace payment can create separate responsibilities to a buyer, seller, platform, provider, and financial institution.
For each participant, document who provides the product, who sets the price, who appears on the statement, who accepts payment, who handles refunds and disputes, who provides tax reporting, and who bears losses. Confirm the proposed model with qualified legal and compliance advisors in every market you plan to serve.
Turn the result into a responsibility matrix with one accountable owner per task. If the agreement says the seller owns a refund but the product lets only the platform issue it, the operating model is already inconsistent.
- Identify the contracting entity for the buyer and for the seller.
- Define who controls seller onboarding, verification, and capability changes.
- Assign ownership for customer support, disputes, refunds, losses, and reporting.
- Record which party may hold, direct, or receive funds at every stage.
Design an immutable ledger around obligations
A seller balance is an accounting view, not a bank account and not proof that cash is immediately available. Represent each economic event as balanced entries: buyer payment, platform fee, seller proceeds, reserve, refund, dispute, payout, return, and correction.
Do not edit the original sale when reality changes. Post a linked adjustment with its own timestamp, actor, reason, and reference. This preserves the history finance needs and lets support explain why the current balance differs from the original order.
- Keep pending, available, reserved, and paid amounts distinct.
- Use one currency per ledger account and record conversion as its own event.
- Require every entry group to balance before it is committed.
- Make manual adjustments permissioned, reason-coded, and independently reviewable.
A useful balance explains what is available, what is pending, and every event that changed it.
Connect seller identity, capabilities, and money movement
Use one durable seller identity across onboarding, verification, payment acceptance, ledger accounts, and payouts. Store capability state separately—such as can accept payments or can receive payouts—because a seller can remain known to the platform while a specific activity is paused.
Make capability changes event-driven. When verification expires or risk review changes a seller’s status, new transactions and payout requests should follow explicit rules while existing obligations remain visible and operable.
- Block an unsupported action before money is accepted, not after the order is confirmed.
- Show sellers what is restricted, what information is required, and what remains accessible.
- Preserve the capability state used when each transaction was created.
- Define how offboarding handles pending orders, reserves, refunds, disputes, and final payouts.
Model fees, fulfillment, and release per order
For each order, calculate the gross payment, platform fee, seller proceeds, tax or other deductions, and reserve before posting entries. Keep the commercial calculation separate from the movement instruction so pricing changes do not rewrite historical transactions.
Choose a release event that reflects the business: shipment, delivery, service completion, or the end of a return window. Record evidence for that event and define what happens when fulfillment is partial, canceled, or split across multiple sellers.
- Store the fee rule version and inputs used for the order.
- Allocate discounts and refunds consistently across platform and seller amounts.
- Prevent a payout from consuming funds still pending release or held in reserve.
- Expose order-level entries so support can explain a seller’s balance.
Design refunds, disputes, and negative balances first
Test the model after proceeds have already been paid out. A partial refund or dispute may create a seller obligation when the seller has no available balance. Decide whether the platform uses a reserve, offsets future proceeds, debits an approved funding source, absorbs the loss, or combines those approaches.
Encode that policy as new ledger entries and visible balance states. Never erase the original allocation. Define limits, notifications, collection steps, and the point at which a negative balance restricts new payment or payout activity.
- Allocate full and partial refunds between platform fees and seller proceeds.
- Track dispute amount, fee, evidence deadline, provisional credit, and final decision separately.
- Set reserve rules and release dates that can be explained to sellers.
- Create an approval path for exceptional loss allocation or balance write-off.
Test the lifecycle and reconcile every layer
Reconcile four views: orders to payments, payments to ledger entries, ledger payout obligations to provider instructions, and provider settlements to bank cash. Use durable references across every layer and place mismatches in an owned exception queue.
Before onboarding live sellers, run scenarios that cross team boundaries. Product, engineering, finance, risk, and support should each be able to locate the same transaction, explain the current obligation, and identify the next allowed action.
- Multi-seller order, split fulfillment, cancellation, and partial refund.
- Seller restriction after payment but before release, and restriction after payout.
- Dispute after payout, negative balance, reserve release, and payout return.
- Duplicate events, delayed events, provider outage, manual adjustment, and seller closure.
