How to Structure Payouts and Commissions in a Service Marketplace

Structuring payouts and commissions in a service marketplace comes down to two systems that should not share the same code: one decides how much each side earns on a booking, and one moves the money to the seller. Get the split rules wrong and you lose margin. Get the payout mechanics wrong and you lose sellers, usually within the first month.

Should commission rules and payout mechanics be built separately?

Commission logic calculates what each party earns on a transaction. Payout logic moves those earnings to a seller's bank account on a schedule. Keep them separate, because commission rules change often while payment rails change rarely.

A commission engine is the set of rules that turns a completed booking into amounts: what the buyer pays, what the platform keeps, what the seller is owed, and what is withheld for tax. It should write to a ledger, which is an append-only record of every money movement in the system. Nothing else should be treated as the source of truth.

Payouts are a different problem. Here you deal with bank accounts, transfer schedules, identity verification, and the fact that money sometimes has to come back. Your payment provider, meaning the company that processes card charges and bank transfers for you, will move funds on request. It will not decide who is owed what. That decision stays with you.

Separation also matters because of change frequency. Pricing experiments, category rates, promotional discounts, and seasonal take rate changes happen monthly in a growing marketplace. Payment rails change every few years. When the two are coupled, every pricing change becomes a payment migration, and payment migrations are where money goes missing.

Which commission model fits a service marketplace?

Most service marketplaces start with a flat percentage of each completed booking, then add tiers, subscriptions, or lead fees once they know which side has pricing power. The model follows who you charge, not what looks standard.

Start with the term. A take rate is the share of each transaction the platform keeps before paying the seller. A reasonable first version for a services marketplace is a flat take rate between 10 and 20 percent, charged to the seller, with the buyer paying the listed price. Charging both sides at launch tends to slow supply growth more than it adds revenue, since sellers are usually the harder side to recruit.

Whichever model you choose, store the rules as data rather than code. Put the rate, the tiers, the category overrides, and the effective dates in tables your operations team can edit. A commission change should be a row in a database, not a deployment on a Friday afternoon.

Where should the money sit between booking and payout?

Money usually sits either in the platform's own account or with the payment provider acting on your behalf. Split payments release the seller's share at charge time, while escrow holds everything until delivery, giving you more control and more responsibility.

A split payment divides one card charge between platform and seller the moment the buyer pays, so the seller's funds never sit with you. Escrow holds the full amount until the service is delivered, which gives you control over timing and refunds, and moves you closer to the rules that govern holding other people's money. Most service marketplaces start with escrow, because the work happens after payment and disputes are common.

Holding funds on behalf of sellers can also trigger money transmission licensing in some jurisdictions. That is one reason many platforms route custody through a provider rather than their own bank account, keeping the commission logic in house and handing over the custody question entirely.

When does the seller get paid?

Pay out after the service is delivered and a short hold period has passed, not when the booking is made. Most marketplaces settle between 24 hours and seven days after completion, depending on dispute risk, refund policy, and fraud exposure.

Three timers usually run at once: the buyer's approval window, the platform's dispute window, and the payout run itself. A hold period is the delay between a job being marked complete and the seller's balance becoming payable. Running payouts once or twice a week on a fixed day keeps transfer costs down. Instant transfers, when offered, can carry a fee of roughly 1 to 3 percent, and passing that cost to the seller is normal.

New sellers are a separate case. A first payout held for 7 to 14 days while identity and bank checks complete is common, and it is far cheaper than chasing a fraudulent seller through a chargeback, which is a card payment reversed by the buyer's bank after the fact.

What belongs in the payout system?

A usable payout system needs a transaction ledger, a balance per seller, a payout schedule, verified bank details, and a refund path that can recover money already sent. Skip any one of these and the gap gets filled with spreadsheets.

A first version needs:

1. Ledger entries for every booking: gross amount, commission, seller payable, tax withheld, adjustments.
2. Balance states per seller: pending, available, reserved, paid out.
3. Identity and bank verification, often called KYC, short for know your customer.
4. A payout run that batches eligible balances on a fixed schedule.
5. An idempotency key on every payout instruction, so a retry cannot pay the same balance twice.
6. Daily reconciliation between your ledger and the provider's settlement report, compared line by line.
7. Seller statements showing what each payout covered.
8. Tax reporting for the jurisdictions you operate in, which in the United States means 1099 forms above the threshold, and in the European Union means DAC7.

Idempotency deserves one more sentence. It means attaching a unique key to each instruction so that repeating the same request returns the original result instead of sending money a second time. Retries are normal in payment systems. Duplicate payouts are not.

Edge cases that break a naive payout build

Refunds after payout, chargebacks, cancelled jobs, partial completions, tips, and currency differences all change a balance that may already have been settled. The system needs adjustments rather than edits to past ledger entries, because an edited history makes reconciliation impossible.

The hardest case is the negative balance, when a seller owes more than their pending earnings cover. Typical fixes are a rolling reserve of roughly 5 to 10 percent of a seller's volume held for 30 to 90 days, a card on file that can be charged, or a temporary payout suspension. State the rule in the seller agreement, because recovering money from someone who has already spent it is slow and rarely worth the legal cost.

Gross merchandise value, the total value of transactions flowing through the marketplace, is the number these rules get expressed against. A 5 percent reserve on a marketplace doing 500,000 in monthly GMV is 25,000 sitting in a separate account, with accounting and cash flow consequences worth modeling before launch.

How long does a payout build take?

A commission rule engine is typically two to four weeks of work. A complete first version, including ledger, balances, payout runs, verification, and statements, usually takes 8 to 14 weeks for a small team.

The rule engine is smaller than it sounds; the surrounding plumbing is not. Expect to spend as much time on statements, reconciliation, and the operations dashboard as on the payout run itself, and budget roughly a day a week for reconciliation once volume is steady.

You can shorten the timeline with a marketplace payments product from your existing provider, which handles money movement and the regulatory side. The trade-off is control: custom commission rules, unusual payout timing, and multi-currency splits often outgrow what a packaged product allows. If you expect to change pricing often or run several seller tiers, building the rule layer yourself while renting the rails is usually cheaper over three to five years. If you would rather not staff that work in house, a team that builds marketplace platforms can take on the ledger, the payout runs, and the admin tooling around them.