Name every participant and responsibility
Start with the buyer, seller, platform, payment provider, and payout destination. For each one, document who provides the product, who accepts the payment, who handles support, and who bears each type of risk.
This is more than a diagram. The responsibilities shape onboarding, transaction records, reporting, disputes, and the agreements your program needs.
Separate money movement from accounting
A balance is an accounting record, not necessarily a bank account or a pool of funds that can move immediately. Define when proceeds become available, which adjustments can affect them, and what a seller is allowed to withdraw.
Keep platform fees, seller proceeds, refunds, disputes, reserves, and payout activity linked to the original sale without collapsing them into a single number.
A useful balance explains what is available, what is pending, and what changed.
Design reversals before launch
Refunds and disputes test the model because the original proceeds may already have been allocated or paid out. Decide how each adjustment affects the platform and seller, and what happens when the available balance is not enough.
Make those rules visible in the ledger and in the operator experience. Manual corrections should remain exceptional, permissioned, and auditable.
Connect the merchant lifecycle
Onboarding, capability changes, payment acceptance, balances, and payouts should share the same merchant identity. That lets the platform respond when a review changes what a seller can do.
A connected lifecycle gives product teams room to improve the customer experience without leaving operations to assemble the truth across separate systems.
