We design and build multi-vendor marketplaces: reliable inventory reservation, one order per seller, an auditable payout ledger and a checkout that survives failure. Start with a 14-day proof of concept.
Design targets · not measured results from past client work
No order accepted for stock that is not available. The stock check and the reservation happen in one database transaction.
Every payout and refund is traceable to ledger entries, and totals reconcile to the payment provider’s reports.
Every payment webhook and order event can be delivered twice without a double charge, double payout or duplicate order.
Every order state change is recorded with who or what caused it, and when.
A multi-vendor marketplace lets many independent sellers sell through one storefront. The platform sits in the middle: it owns the catalogue and checkout, splits each cart into orders per seller, takes payment once, divides the money between sellers and itself, and pays sellers out later. That makes three things harder than in a single-shop store: keeping stock correct, keeping orders and returns per seller, and keeping an auditable record of who is owed what.
Available stock is on hand minus reserved. A reservation must succeed or fail atomically, so two buyers cannot take the same last unit.
One parent order represents the customer’s payment. One child order per seller carries that seller’s items, shipment and returns.
A ledger of append-only entries records payments, commission, refunds and payouts. Balances are computed from entries, never edited.
Orders, money and stock are where marketplaces fail. Each pillar addresses one of them.
A marketplace cart becomes one parent order for the customer and one child order per seller. Each child order has its own fulfilment, shipment and return path, driven by a clear state machine and events that are safe to replay.
Money movement is recorded as append-only ledger entries, never as an editable balance field. A seller’s balance is the sum of its entries, so every number can be explained, and returns and disputes are new entries rather than edits.
Available stock is on hand minus reserved, and a reservation succeeds only if enough is available, checked and written in one atomic step. Caches speed up browsing, but the database decides who gets the last unit.
Not every marketplace needs custom engineering. This table shows where each route usually fits, and where it starts to hurt.
| Situation | Typical fit | Why it fits | Watch out for |
|---|---|---|---|
| Standard catalogue, few sellers, need to test demand quickly | A marketplace product or hosted platform | Fastest route to a working marketplace, with common features already built. | Customizing fees, payout rules or workflows can be limited. Check this before you commit. |
| Distinctive workflows: unusual fees, B2B rules, complex fulfilment | A custom build | Orders, payouts and pricing follow your business rules rather than a product’s model. | More to build and operate. Start with the hardest parts and a proof of concept. |
| Mostly standard, but one area is unusual (payouts, stock or pricing) | Hybrid: a product for the storefront plus custom services for that area | You keep what is commodity and build only where you differ. | Integration seams need clear contracts and ownership, or they become the failure point. |
| Heavy integration with ERP, warehouse or legacy systems | Custom or hybrid, with an integration layer | Adapters and events isolate the marketplace from slow or fragile backends. | Test against the real systems early. Our API gateway page covers the adapter pattern. |
This is guidance, not a verdict. We assess your catalogue, sellers, volumes and integrations before recommending a route.
On Stripe Connect, the charge type decides who the merchant of record is and which balance is debited for disputes and fees. Other providers have comparable choices, so settle this before you build the payment flow.
| Charge type | Typical marketplace fit | Who is debited for disputes | Watch out for |
|---|---|---|---|
| Direct charges | Sellers sell in their own name | Stripe attempts to debit the connected account’s balance; if it cannot, responsibility depends on who is responsible for negative balances. | Dispute fees depend on the connected account’s fee configuration. |
| Destination charges | Each payment involves a single seller | Stripe debits the platform account for the dispute amount and fees. Refunds also come from the platform balance. | Recover funds from the seller by reversing the transfer, ideally from a webhook on the dispute event. A refund can reverse the transfer too, and the platform’s application fee is not returned unless you ask for it. |
| Separate charges and transfers | One cart paying several sellers | Stripe debits the platform account. The platform is the merchant of record and its balance bears fees, refunds and chargebacks. | Refunding a charge does not change its transfers, so the platform must reconcile what the seller owes by reversing a transfer or reducing a later one. A transfer fails if it exceeds the platform’s available balance. Use source_transaction, and check how automatic payouts interact with transfers. |
Based on Stripe’s Connect documentation at the time of review. Check the current documentation and take legal and tax advice for your markets.
Illustrative figures with a flat 10% commission and payment processing fees ignored. The point is that the ledger always balances, and a return is a new entry rather than an edit.
| Record | Amount | What it means |
|---|---|---|
| Parent order P-1001 | 150.00 | One payment from the customer. |
| Child order C-1 (Seller A) | 60.00 | Commission 6.00, seller share 54.00. |
| Child order C-2 (Seller B) | 50.00 | Commission 5.00, seller share 45.00. |
| Child order C-3 (Seller C) | 40.00 | Commission 4.00, seller share 36.00. |
| Ledger check | 135.00 + 15.00 | Seller shares plus commission equal the 150.00 the customer paid. |
| Customer returns C-2 | −50.00 | Refund the customer, then add entries reversing the 45.00 seller share and the 5.00 commission. Nothing is edited or deleted. If Seller B was already paid, the reversal makes their balance negative and the next payout run recovers it. On Stripe’s separate charges and transfers, refunding the charge does not touch the transfers, so this reconciliation is your platform’s job. |
Stock, payment and orders live in different systems, so no single database transaction covers them. A saga breaks checkout into local steps, each with a defined way to undo it.
| State | What happens | If it fails or expires | Next |
|---|---|---|---|
| Reserving | Stock is reserved atomically for each item, with an expiry time. | Nothing reserved; the customer is told what is unavailable. | Payment pending |
| Payment pending | The customer pays. The provider’s webhook confirms the result. | The reservation is released on failure or expiry. | Paid |
| Paid | The parent order and child orders are created, and the ledger records the payment, in one transaction with an outbox event. | If order creation cannot complete, the payment is refunded and the reservation released. | Confirmed |
| Confirmed | Each seller is notified through an outbox event and fulfils their child order. | A seller who cannot fulfil triggers a partial refund and a ledger reversal. | Fulfilled or refunded |
In saga terms, the successful payment is the pivot: after it, the flow moves forward with retryable, idempotent steps rather than rolling back.
Core building blocks we include in a marketplace engagement.
Seller-managed listings with variants and attributes, indexed for fast faceted search. The search index is updated from catalogue events, so listings and search stay in step.
Platform and seller-level promotions, volume tiers and B2B price lists, evaluated by one rules layer so the cart and checkout always agree on the price.
Hosted payment fields keep card numbers off your servers, and the payment provider handles strong customer authentication where required. Splits and payouts run from the ledger, not from the checkout request.
Seller identity checks through the payment provider’s onboarding, tax calculation through a tax service, and the records you need for reporting. Your obligations depend on where you sell, so we map them with you.
The core of overselling prevention is one conditional update. It checks and reserves in the same statement, so the database serializes competing buyers.
-- inventory(sku_id, warehouse_id, on_hand, reserved)
-- available = on_hand - reserved
BEGIN;
UPDATE inventory
SET reserved = reserved + :qty
WHERE sku_id = :sku
AND warehouse_id = :wh
AND on_hand - reserved >= :qty;
-- 1 row updated -> stock reserved
-- 0 rows updated -> not enough stock, nothing changed
INSERT INTO reservations (id, order_ref, sku_id, warehouse_id, qty, expires_at)
VALUES (:id, :order_ref, :sku, :wh, :qty, now() + interval '15 minutes');
COMMIT;
-- A scheduled job releases expired reservations:
-- reserved = reserved - qty, then marks the reservation released.Because the check and the update are one statement, two buyers cannot both take the last unit. The reservation row records who holds the stock and when it expires. A cache can serve browse pages, but it should never be the thing that decides availability.
Six failure patterns we design against from the first week.
When a seller’s balance is one number that code updates, nobody can explain a mismatch later. Record entries and compute the balance from them.
A cache or a lock in front of the database can still let two requests through if it fails or expires. Correctness belongs in an atomic database check, with the cache used for reads.
Sellers ship separately and return separately. A single order forces awkward partial states. Use a parent order with a child order per seller.
Payment providers can retry, and events can arrive out of order. Store each event ID, process it once and check the current state before acting.
A return or dispute can arrive days later. Hold payouts for an agreed window, and decide in advance who covers a seller whose balance goes negative.
Who sells to the customer decides tax duties, refunds, chargebacks and which payment flow fits. Settle it before you build the payment flow.
A storefront, a few test sellers and a working checkout deployed in a dedicated environment, using the payment provider’s test mode.
A dashboard for stock reservations, parent and child orders, ledger entries and payout runs, so you can see how each number was reached.
Database schema, event contracts, infrastructure as code and load-test scripts, ready for your engineers to run and extend.
Six questions to ask any firm, including us, and the evidence to request.
Ask how seller balances are recorded and how a refund after payout is handled. Evidence to request: a sample ledger schema and a worked reversal.
Ask how two buyers for the last unit are handled. Evidence to request: the reservation query or design, and the concurrency test that proves it.
Ask how a cart with several sellers is modelled, shipped and returned. Look for parent and child orders and per-seller states.
Ask who the merchant of record will be and what that means for tax, refunds and chargebacks. Look for a clear recommendation tied to your markets.
Ask what happens when payment succeeds and order creation fails. Look for outbox, idempotent consumers and a compensating flow.
Ask what you own at the end. Look for source code, infrastructure as code, runbooks and training handed over, with acceptance criteria agreed up front.
It is a platform where many independent sellers list and sell products through one storefront. The platform takes the customer’s payment, splits the cart into orders per seller, divides the money between sellers and itself, and pays sellers out, usually after a hold for returns and disputes.
Check and reserve stock in one atomic database step: increase the reserved quantity only if on hand minus reserved covers the request. Give each reservation an expiry so abandoned checkouts release stock. Caches can speed up browsing, but the database should decide who gets the last unit.
A parent order represents the customer’s purchase and payment. Each seller in the cart gets a child order holding their items, shipment, status and returns. This lets one seller ship or refund without disturbing the others.
A balance field only shows the current number. A ledger of append-only entries shows how it was reached, so a refund, commission or dispute is a new entry rather than an edit. The balance is the sum of the entries, and it can be reconciled against the payment provider’s reports.
It depends on the payment flow. In Stripe Connect, for destination charges and for separate charges and transfers, Stripe debits dispute amounts and fees from the platform account, and the platform can try to recover funds from the seller by reversing the transfer. Refunds also come from the platform balance for those charge types, and a refund stays pending if the platform balance is short. With direct charges, Stripe debits the disputed amount from the connected account’s balance. Take legal and tax advice for your markets.
Design checkout as a saga. Write the order and an outbox event in the same transaction as the payment record, and make later steps idempotent. If order creation cannot be completed, run a compensating step: refund the payment and release the reserved stock.
It depends on the number of seller types, payment flows, integrations and markets. We do not publish a flat price, because any figure would mislead. A proof of concept on the hardest part of your design is the quickest way to get a realistic estimate, and we deliver that as a 14-day sandbox.
Work with our principal architects to blueprint the order, inventory and payout engine for your marketplace.