Marketplace Split Payments, Escrow and Seller Payouts Explained

A marketplace split payment takes one customer payment, keeps the platform's commission, and owes the rest to each seller, usually after a hold until the order is delivered. That hold is not escrow in the legal sense; Stripe, for one, says it does not provide escrow. What you build is a ledger: one record per seller per order, released by a rule, then paid out.

This guide covers the money logic that sits behind any gateway: when a seller's money becomes theirs, how refunds after a payout are handled, and how to keep every figure correct to the last paisa or cent. If you are building on Stripe specifically, account types, charge types and Connect fees are covered in Stripe Connect for marketplaces; this post does not repeat them.

What is a marketplace split payment?

It is one payment that belongs to more than one party. A customer pays 3,000 taka for items from two sellers; the platform keeps its commission on each item; each seller is owed their share. The gateway may do the split for you, or the platform may collect everything and pay sellers itself. There are three common models.

Model	Who holds the money until payout	Who carries refund risk after payout	Fits when
Gateway-managed split (for example Stripe Connect)	The gateway, in the platform's or seller's balance	Depends on the charge type; often the platform	Sellers are in countries the gateway supports
Platform collects, then pays sellers	The platform's merchant account	The platform, which must recover it from future payouts	Local gateways and mobile wallets with no split feature
Cash on delivery	The courier, then the platform after remittance	The platform	Markets where many buyers pay cash at the door

Many marketplaces run more than one model at once. The money arrives by different routes and at different speeds, but the seller should see one balance. That is why the ledger, not the gateway, has to be the source of truth.

Is holding seller funds the same as escrow?

No, and the word matters. Stripe's documentation says: "Escrow has a precise legal definition, and Stripe doesn't provide escrow services or support escrow accounts. However, you can control payout timing through manual payouts, which allow you to delay payouts to certain accounts" (Stripe: manual payouts).

What most marketplaces actually need is a payout hold: the seller's share is recorded but not paid until the order is delivered and a return window has passed. Even that has limits. On Stripe, funds held with manual payouts must be paid out within a period set by the business's country:

Business country	Maximum holding period with manual payouts
Thailand	10 days
United States	2 years
All other countries	90 days

Figures from Stripe's manual payouts page, checked on 29 September 2026. If you collect money yourself and pay sellers later, holding customers' money on behalf of others can be a regulated activity in some countries. This is general information, not legal advice; confirm with your adviser before you design the money flow, and avoid calling a payout hold "escrow" in your terms unless a licensed escrow provider is involved.

How should money move for one order?

Through a small set of states, each with a clear trigger. A seller's share should never jump straight from "paid by customer" to "paid out".

1. Captured. The customer pays. The platform records each order line's gross amount, commission and seller share, in integer minor units, in the same database transaction that creates the order.
2. Pending. The seller's share is owed but not yet theirs to withdraw. The order may still be cancelled or refunded.
3. Available. The order is delivered and the return window has passed. The share can be paid out.
4. Paid. The share is included in a payout that has been sent.

Refunds follow the same rule in reverse. A refund before payout cancels the pending share. A refund after payout creates a negative entry, which reduces the seller's next payout. The seller's balance can go below zero for a while, and your design has to allow for that.

What does a payout ledger look like in SQL?

An append-only table of signed entries. Sales are positive; commission and refunds are negative; each entry carries a status and, while pending, a release time. A minimal PostgreSQL sketch, assuming sellers and order_lines tables already exist:

CREATE TABLE payouts (
  id            bigserial PRIMARY KEY,
  seller_id     bigint NOT NULL REFERENCES sellers(id),
  amount_minor  bigint,                      -- set when the payout is confirmed
  status        text NOT NULL DEFAULT 'draft'
                CHECK (status IN ('draft', 'requested', 'sent', 'failed')),
  created_at    timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE seller_ledger (
  id            bigserial PRIMARY KEY,
  seller_id     bigint NOT NULL REFERENCES sellers(id),
  order_line_id bigint REFERENCES order_lines(id),
  payout_id     bigint REFERENCES payouts(id),
  kind          text NOT NULL CHECK (kind IN ('sale', 'commission', 'refund', 'adjustment')),
  amount_minor  bigint NOT NULL,             -- signed, in paisa or cents
  status        text NOT NULL DEFAULT 'pending'
                CHECK (status IN ('pending', 'available', 'paid')),
  available_at  timestamptz,                 -- set when the order is delivered
  created_at    timestamptz NOT NULL DEFAULT now()
);

When an order is delivered, start the hold. The 7 days here is an example; use your own return policy.

-- On delivery: the hold starts now.
UPDATE seller_ledger
SET available_at = now() + interval '7 days'
WHERE order_line_id = ANY($1) AND status = 'pending';

-- On a schedule: release entries whose hold has ended.
UPDATE seller_ledger
SET status = 'available'
WHERE status = 'pending' AND available_at <= now();

A payout marks entries as paid and sums exactly the entries it marked, inside one transaction. Locking the seller's row stops two payout runs for the same seller from overlapping; PostgreSQL's FOR UPDATE blocks other transactions from locking or changing that row "until the current transaction ends" (PostgreSQL: explicit locking).

BEGIN;
SELECT 1 FROM sellers WHERE id = $1 FOR UPDATE;   -- one payout run per seller

INSERT INTO payouts (seller_id) VALUES ($1) RETURNING id;   -- call it $2

WITH paid AS (
  UPDATE seller_ledger
  SET status = 'paid', payout_id = $2
  WHERE seller_id = $1 AND status = 'available'
  RETURNING amount_minor
)
SELECT COALESCE(SUM(amount_minor), 0) AS due FROM paid;

-- In application code: if due <= 0, ROLLBACK (a negative balance waits for
-- new sales). Otherwise:
UPDATE payouts SET amount_minor = $3, status = 'requested' WHERE id = $2;
COMMIT;

Summing the rows the UPDATE returned, rather than a separate SELECT first, means an entry released between two statements cannot be marked paid without being counted. Send the money to the gateway after the commit, using the payout's ID as the idempotency key or reference, so a retry cannot pay the seller twice. The pattern is explained in idempotency in API design.

How does TheSkinProof handle commission and seller payouts?

TheSkinProof is the founder's own venture, a verified-skincare marketplace built and run by RAITHub, not a client project, so read it as engineering evidence rather than a client reference. It has 217 API endpoints, 5 role-based portals and 750+ automated tests.

• Commission per order line. Each line records the seller, the commission held back and the seller's share, so a refund or payout lands on the right seller. The rate lives on the line, not on the seller, so a category rate or a promotion changes one field without rewriting history.
• Written with the order. Settlement rows are created in the same database transaction as the order, so a refund can reverse exactly what was recorded.
• Four ways to pay. Customers pay through bKash, Nagad, SSLCommerz or cash on delivery. Whichever rail the money arrives on, the ledger, not the gateway, decides what each seller is owed.
• Payouts in the seller portal. Sellers see their own payouts and data, scoped to them on the server.

The arithmetic behind per-seller settlement is shown in TypeScript in Sharetribe vs a custom marketplace, and the full platform is on the TheSkinProof case study.

What goes wrong with marketplace payouts?

The same six mistakes appear again and again, and each one costs real money.

• Floating-point money. 0.1 + 0.2 is not 0.3 in JavaScript. Store integer minor units and round in one place.
• Commission computed later from current settings. Change the rate next month and last month's orders silently change. Store the rate and the amount on the line when the order is placed.
• Paying out before the return window ends. Refunds then come out of the platform's pocket, and recovering them from a seller who has stopped selling is hard.
• No negative balances. If the ledger cannot go below zero, refunds after payout get lost or patched by hand.
• Non-idempotent payout calls. A timeout, a retry, and the seller is paid twice.
• Cash on delivery treated as paid. With cash, the money is with the courier until it is remitted. The seller's share should only become available once the courier's remittance has been matched to the order.

Why RAITHub for this

• Marketplace money logic in production. TheSkinProof, the founder's own venture, runs per-seller commission across 4 payment rails. PropDesk, a property management platform, collects rent through Stripe with 1,024 tests. PadhAI, an AI tutoring platform RAITHub built, supports 9 payment gateways.
• Money paths are tested. Commission, refunds before and after payout, and the "runs twice" case get automated tests gated in CI.
• Fixed scope, your code. A free 15-minute technical audit, then a written fixed quote. You own the code; an NDA is standard. See the API and backend development service.

When you don't need us

• Your gateway does the split and your rules are simple. One seller per order, one commission rate, sellers in supported countries: the gateway's built-in marketplace features and its documentation may be all you need.
• You are still validating demand. A hosted marketplace platform is cheaper while you learn whether buyers and sellers will transact.
• You need licensing, escrow or tax advice. That is for a payments lawyer or tax adviser. RAITHub builds the software, not the legal structure.

For the wider build, see custom ecommerce and marketplace development, the cost to build a marketplace platform and the ecommerce industry page. To plan your payout design, book the free 15-minute technical audit with your payment methods, sellers' countries and refund policy.

Last reviewed: 29 September 2026. Stripe and PostgreSQL documentation checked on 29 September 2026.

Frequently asked questions

How do marketplace split payments work?

The customer pays once. The platform records, for each order line, the commission it keeps and the share owed to the seller. The gateway may split the money automatically, or the platform collects it and pays each seller later from a ledger.

Is a marketplace payout hold the same as escrow?

No. Escrow has a precise legal meaning. Stripe says it does not provide escrow services but lets platforms delay payouts through manual payouts. Confirm with your adviser before using the word in your terms.

How long can a marketplace hold seller funds on Stripe?

With manual payouts, Stripe says funds must be paid out within 10 days for businesses in Thailand, 2 years in the United States, and 90 days in all other countries.

What happens if a customer is refunded after the seller was paid?

Record a negative entry in the seller's ledger. It reduces the seller's next payout, and the balance may go below zero until new sales cover it.

When should a seller's money become available for payout?

After the order is delivered and your return window has passed. For cash on delivery, only after the courier has remitted the cash and it has been matched to the order.

Should commission be stored or calculated?

Stored, on each order line, when the order is placed. Calculating it later from current settings means a rate change silently rewrites past orders and payouts.