I build the money layer for marketplaces: split payments, seller ledgers, commission engines, settlement cycles and dispute-proof statements — so every seller knows exactly what they’re owed and why, and so do you.
Why is marketplace money deceptively vicious?
Because one order is never one transaction. A single sale explodes into a payment in, a commission out, maybe a promo subsidy, a shipping fee, a payment-gateway charge — then a return three days later, a partial refund, and a seller settlement running on a different calendar than the gateway’s settlement to you. Multiply by ten thousand orders across hundreds of sellers, and the question “how much do we owe seller #482, and why?” becomes genuinely hard — not conceptually, but arithmetically, in the way that breaks spreadsheets and burns trust.
And trust is the actual inventory. Sellers tolerate a worse take-rate before they tolerate an unexplained payout; nothing churns supply like “payout kahan hai?” answered with silence. Udhaar culture runs on bharosa, but platforms don’t get that credit — a marketplace’s word is only as good as its statements, and its statements are only as good as its ledger.
What does the marketplace money layer include?
- Per-seller double-entry ledgers. Every order’s splits — item value, commission, fees, promos, adjustments — posted as immutable entries against the seller’s account. The seller balance is a projection you can replay, which means every payout is an arithmetic conclusion rather than a batch job’s opinion. The architecture is the same one that runs lending books; sellers are creditors wearing storefronts.
- The commission and fee engine. Category rates, slabs, promotional subsidies and penalties as configurable rules with effective dates — changes roll forward, history stays true, and the take-rate report reflects reality by construction.
- Settlement cycles with holds and reserves. T+n schedules, return-window holds, risk reserves and minimum thresholds encoded as policy; payout files generated, acknowledged and reconciled against the bank — the payments discipline applied to the outbound leg.
- Statements sellers can audit themselves. Self-serve, drilling from payout to order to fee line. Most disputes end at the drill-down; the rest end quickly because both sides finally read the same numbers.
- Platform truth for you. Take-rate by category computed rather than estimated, promo-spend visibility, receivable-from-gateway versus payable-to-sellers reconciled daily — the float you’re actually sitting on, known instead of felt.
What breaks first without this?
Reconciliation, always. The gateway settles net of its fees on its calendar; you owe sellers gross-minus-commission on yours; returns cross the boundary in both directions — and the spreadsheet holding it together develops a small unexplained gap that grows with GMV. By festival season the gap has a lakh-figure and nobody can say which sellers it belongs to. The fix sequence is proven: daily three-way reconciliation retrofitted first — orders against gateway settlements against payouts — then the seller ledger migrated with parallel runs once the bleeding stops. The reconciliation engagement is exactly this rescue, written up.
What does seller trust look like as a metric?
Payout-dispute tickets per thousand settlements — and it should trend toward zero. When statements drill to the order line, when holds carry stated reasons, when the payout date is a promise the system keeps automatically, sellers stop maintaining their own shadow books and start listing more inventory. Marketplaces win supply with transparency they can prove — the hisaab is the growth hack, seedhi baat. The platforms my teardown series covers learned this early: settlement reliability is retention infrastructure wearing a finance costume.
Related reading
/industries/payments — the inbound leg · /blog/reconciliation-at-scale — the method · /products/ledger-platform — the deployable core · /work/reconciliation — the rescue, documented
The seller-support test
If seller-support tickets starting with “payout kahan hai” are a category in your helpdesk — /contact. Sellers who trust the hisaab sell more; that’s the cheapest GMV you’ll ever buy.
Questions I actually get
We are on spreadsheets and festival volume is coming. What is the emergency path?
Stabilise reconciliation first — the seller-ledger core can wait a month, the daily matching of orders, gateway settlements and payout files cannot. That two-week retrofit stops the bleeding before peak season, and the full ledger migrates after the rush with parallel runs. Sequencing is the rescue.
How do returns and COD fit into the ledger?
As first-class events, not adjustments — a return posts its own entries reversing the right legs, and COD reconciles collection-to-deposit-to-settlement as its own chain. In Indian e-commerce COD and returns are half the plot; any system that treats them as exceptions has misread the market it is accounting for.
Are the gateways' split-settlement products enough?
They split money in flight; they do not keep your books. You still need the ledger that explains history — what was owed, what was held, why this payout is this amount — and the statement your seller reads when they dispute. Use split-settlement rails happily; just do not mistake plumbing for accounting.
Can sellers really self-serve their statements?
Yes — per-seller statements drill from payout to order to individual fee line, generated from the same entries your books run on. Most payout disputes die at the drill-down, because the question was never bad faith; it was opacity. Transparency is the cheapest seller-retention feature you can ship.
How do commission and promo changes roll out safely?
As configuration with effective dates — new rates apply from a date, old orders keep their old rules, and the transition is auditable. The alternative, editing rates in place, silently rewrites history and is exactly how take-rate reports become fiction. Rules with dates; never edits.
What scale does this architecture handle?
The pattern — event-sourced entries, projected balances, daily reconciliation — is the same one my teardowns document at national payment volume. Postgres-backed and partition-ready, it grows by configuration rather than re-architecture; marketplace order volumes are well inside its comfort zone.