Building a Marketplace from Scratch: Architecture, Sellers, Payments and Monetization
How a marketplace differs from an online store
The most common and most expensive mistake at the start is treating a marketplace as «an online store that lets in several sellers». At the storefront level the difference is invisible: catalog, product page, cart, checkout. At the business-logic level these are two different products.
In an online store you are the only seller. You own the goods, the price, the stock, the shipping and the money. In a marketplace you are a platform operator that connects buyers with dozens or hundreds of independent sellers. You don't own the goods, but you are responsible for settlements, disputes, moderation quality and trust. The buyer's money flows through you, but belongs to the seller. This shift — from «I sell» to «I am the settlement and trust hub» — defines the entire architecture.
Store: one seller, one stock pool, one settlement party, simple accounting.
Marketplace: N sellers, N offers inside one catalog, payment splitting, mutual settlements, commission withholding, payouts, plus disputes and returns handled per seller.
Multivendor architecture
The core of a marketplace is the «seller» (merchant) entity, to which almost everything is attached: products, stock, prices, orders, balances, documents and ratings. The catalog, however, must be shared: a single product (say, a specific smartphone model) is one card, while the offers of different sellers with different prices and lead times are offers inside it. This «product → offers» model lets buyers compare sellers and decide who wins the default «Buy» button.
A buyer's order is almost never equal to one seller's order. A cart containing goods from three sellers must split at checkout into three shipments, with separate tracking, separate statuses and separate financial fates. If you model the order as a monolith at the start, you'll have to rewrite the most painful part of the system later.
- Seller dashboard: uploading products, managing prices and stock, processing orders, exporting documents, viewing balance and payout history.
- Moderation: vetting new sellers and listings, fighting duplicates, prohibited categories and fake stock.
- Platform billing: calculating commissions, penalties and bonuses, generating payout instructions.
Payments, splitting and escrow
The most sensitive block is money. When a buyer pays, the funds must not flow to the seller instantly. In the Uzbekistan market payments usually go through Click, Payme and Uzum, plus cash on delivery, which adds a whole separate layer of cash reconciliation for a marketplace. The buyer's money must be held until the order is confirmed as delivered and not cancelled, and only then split: the platform commission to you, the remainder to the seller.
This is exactly the escrow logic: the platform acts as a guarantor. The buyer trusts that money will be refunded if something goes wrong, and the seller trusts they'll be paid once the order is fulfilled. Technically this is implemented through internal balances and a transaction ledger, where every money movement is a separate immutable record with double entry — «from → to».
Common mistake: storing a seller's balance as a single number in a table and updating it on the fly. On a failure, a duplicate webhook from the payment provider, or a race condition, the balance drifts and it becomes impossible to prove who owes whom. Money must be computed only as the sum of immutable ledger records, and webhooks must be idempotent — a repeated call must never credit twice.
Key decision: operate as an aggregator (money flows through your account and you make payouts yourself) or as a platform where the payment provider splits the payment between merchants directly. The first option is more flexible for monetization but adds licensing, tax and accounting obligations — settle this with a lawyer and a bank before writing code, not after.
Logistics and fulfillment
In a store, delivery is a nice add-on. In a marketplace it is part of the product. You need to choose the base model: sellers ship themselves (FBS), or the platform takes goods into its own warehouse and ships on the seller's behalf (fulfillment, FBO). Most platforms eventually support both.
Technically this means integrations with courier services and pickup points, calculating cost and lead time, printing labels, unified tracking for the buyer, and reconciliation: who shipped, who delivered, who collected cash from the courier. In the Uzbekistan market this is compounded by geography — regional delivery, different tariffs by province, and a significant share of cash on delivery that must be reconciled daily against collected cash.
Monetization
A marketplace earns not on product margin but on the infrastructure around the deal. The main models usually combine:
- Sales commission — a percentage of each completed order, often varying by category.
- Paid promotion — in-catalog ads, ranking boosts, banners.
- Seller subscription — tiered plans with different limits and tools.
- Paid services — fulfillment, storage, acquiring, working-capital lending.
Architecturally, it's critical that commission rules are configurable rather than hardcoded. Categories, promotions, individual rates for large sellers, temporary promos — all of this changes constantly, and each change must not require a release.
Load and resilience
A marketplace breaks not under average traffic but under spikes: sales, holidays, ad campaigns. At those moments catalog reads, search, checkout and calls to payment gateways all grow at the same time.
This is why catalog and search should be separated from the transactional part and served via a dedicated search engine and cache — reads must scale independently. Checkout, stock decrement and payment operations, on the contrary, require strict consistency: two buyers must not both buy the same last item. Heavy operations — notifications, document generation, synchronization with sellers and logistics — are pushed to queues and processed asynchronously, so a load spike doesn't bring down checkout.
Conclusion
A marketplace is not a store with several sellers but a settlement-and-trust platform, where the main risks lie in money, disputes and peak load rather than in the storefront. Build in the multivendor model, a ledger instead of a single-number balance, idempotent payments, configurable commissions, and the separation of reads from transactions from day one — reworking this under load is expensive and painful. If you're planning to launch a marketplace for the Uzbekistan market, the OneDev team can help design the architecture and monetization around your model — let's discuss your project.
How much time and resources does launching a marketplace take?
Can I convert an existing online store into a marketplace?
Do I need a payment license?
What is escrow in simple terms?
How do you attract the first sellers to an empty platform?
How do you handle cash on delivery and cash reconciliation?
Need a similar system or want to discuss your project?
Describe the task — we will propose architecture, technical approach and a work plan. A short call is usually enough to get started.
Discuss project