Sooner or later in a planning meeting, someone points at a famous marketplace and says “like that”. It is a useful moment, because it gives the team a shared picture. It is also where a lot of plans go wrong, because the picture is of the storefront, and most of the operating decisions sit behind it.
Most multi vendor marketplace examples, and most online marketplace examples in general, differ less in what they sell than in who holds the stock, who holds the money and who carries the credit. One marketplace stores and ships sellers’ goods. Another lets sellers ship their own orders. One pays sellers as soon as an order is placed, another holds the money until the service has happened, and a third lets buyers pay later while it carries the wait. Each of those is an operating decision, and each one asks something of the business that makes it: stock records, payout timing, credit risk and an accounting system that has to agree with all of it.
So this article uses a few examples and reads each one for the decision behind it. For each, it covers what the marketplace does, according to its own published pages, and what copying that decision would ask of a smaller marketplace. The examples are grouped by decision. There is no ranking, and none of them is the model to follow. The useful question is which decisions you can run with the team, systems and cash you have.
Questions to settle before you copy a model
What makes one marketplace business model different from another?
Mostly where orders, stock and money are held, and who answers for them. The same holds for most marketplace business model examples you will read about. Two marketplaces selling similar products can run very differently if one holds stock and the other never touches it, or if one pays sellers on order and the other on delivery.
Do the famous online marketplace examples apply to a smaller business?
Some of their decisions do, and some depend on scale you may not have yet. A decision is worth copying when you can also run what it requires: the warehouse, the payout rules, the credit checks and the reconciliation.
Are b2b marketplace examples different from consumer ones?
Often, yes, mainly in payment. Business buyers may expect invoices and payment terms, which means someone carries the credit between the order and the payment. Consumer marketplaces usually take payment at checkout.
What changes in service marketplace examples?
The thing being sold is a time slot or a piece of work, so there is no stock to count. In its place there is a calendar, a booking that can be cancelled, and a question of when the provider is paid relative to when the work happens.
Should a new marketplace hold stock itself?
That depends on whether you can run a warehouse and the stock records that go with it. Holding stock gives you control over delivery and returns. It also makes every unit something you have to count, store and answer for.
Who holds stock and ships
A marketplace that stores and ships for sellers
With Fulfillment by Amazon, sellers send their products into Amazon’s fulfilment centres, and Amazon picks, packs and ships the orders and handles customer service and returns for them. The same page explains that sellers can choose some or all of their eligible products for the programme and compare it with their own fulfilment, so one seller can have stock in both places.
The decision behind it is that the marketplace takes over the physical side of the sale for sellers who opt in. The buyer gets one delivery and returns experience, whoever the seller is.
What it asks of a smaller marketplace is considerable. Once you hold sellers’ stock, you need stock records per seller, per product and per location. You need a receiving process that checks what arrived against what was sent. You need to know which units are reserved for open orders, so the same item is never promised twice. Returns have to go back into the right seller’s stock, or be written off and accounted for. And your accounting has to separate stock you own from stock you only hold for someone else. None of that is visible on a storefront, and all of it is the reason the model works.
Marketplaces where sellers ship their own orders
The other common arrangement is that each seller keeps their own inventory and ships their own orders. The marketplace passes the order on and records what happened. This is how many multi-vendor marketplaces start, because it asks the least of the operator on day one.
The trade-off moves to consistency. Delivery times, packaging and returns depend on each seller. A buyer who orders from three vendors may get three parcels on three days, with three returns processes. The marketplace still has to know where each order is, so it needs shipping updates from every seller, and a rule for what happens when a seller does not ship on time.
It also needs to decide what it promises the buyer. If the marketplace shows one delivery estimate for the whole basket, it is promising on behalf of every seller in it. If each seller’s estimate is shown separately, the promise stays with the seller, and the buyer sees the difference before paying. Either way, the order record has to hold each seller’s part of the order with its own shipping status, because one basket can be partly delivered, partly late and partly refunded at the same time.
There are also mixed models. A marketplace may hold stock for a few high-volume sellers and let the rest ship themselves. That gives flexibility, but every order then has two possible paths, and your stock records, shipping updates and returns rules have to cover both.
When the seller gets paid
Payout timing looks like a finance detail for the ecommerce team to sort out later. In practice it shapes how sellers see the marketplace, how much risk the marketplace carries, and how much of the buyers’ money sits in its accounts at any time.
Paying after the service happens
Airbnb’s help page on payout timing says that for most shorter home stays it starts the host’s payout after the guest’s scheduled check-in, and that timing also depends on the type of reservation, the payout method and whether the host is new.
The decision behind it is to hold the money until the thing being paid for has started. If a booking is cancelled or the listing does not match, the money has not yet left.
Copying that decision asks several things of a smaller marketplace. You need a clear record of money held for each booking and each provider, separate from the marketplace’s own income. You need rules for cancellations before and after the payout date, including who bears any refund. You need a payout process that runs on event dates, which means the system has to know when each service actually starts. And your accounting has to show held funds, released payouts and commission as separate lines, or month-end becomes a reconstruction exercise. Whether you can hold buyers’ money at all, and on what terms, depends on your payment provider and local rules, which need a lawyer or an accountant to confirm.
Paying on order or on delivery
A marketplace selling goods can pay sellers when the order is placed, when it ships, or after it is delivered and any return window has closed. Paying early keeps sellers happy and the held balance small, but refunds then have to be recovered from sellers. Paying late protects the marketplace and the buyer, but sellers wait longer for their money and may ask why. Most of the work sits in the rules for partial refunds, split orders and disputes, which is where a clear approach to marketplace payment splitting earns its keep.
This is the kind of rule that changes after launch. A network marketplace in Dubai that KVY built and still runs is multi-seller commerce in production with ongoing stewardship, so the team that built it is the team that changes it when seller or payout rules change. Payout rules touch orders, refunds, commission and the accounts at once, and the people changing them need to know where each of those is recorded. Pixerf, a two-sided creative marketplace in Singapore that KVY delivered on an older custom stack, ran photographer bookings, licensing and payouts for 50,000+ creators.
Who carries the buyer’s credit
On Faire, described on its own site as an online wholesale marketplace where brands list products and retailers buy at wholesale, eligible retailers can use 60-day payment terms, which let them buy inventory and pay 60 days later.
The decision behind it is that the marketplace stands between the buyer’s payment date and the seller. Retailers get time to sell before they pay, and the marketplace decides who is eligible and how much they can spend on terms.
This is where b2b marketplace examples ask the most of a smaller operator. If you offer payment terms, someone has to fund the gap, and someone has to decide who qualifies. You need a credit limit per buyer, a record of how much of it is in use, invoices with due dates, reminders, and a process for late payment. The seller’s payout has to be decided independently of whether the buyer has paid yet. And your accounting has to carry receivables from buyers and payables to sellers at the same time, matched order by order. A marketplace that offers terms without those records quickly finds it does not know who owes what.
There are lighter versions. A marketplace can let sellers offer terms to buyers they already know, with the marketplace only recording the invoice. Or it can work with a third party that carries the credit. Each moves the risk to a different place, and each needs the order, the invoice and the payment to stay linked.
Selling time instead of goods
Service marketplace examples replace stock with time. A provider offers slots or pieces of work, a buyer books one, and the work happens later. There is nothing to put on a shelf, but there is a lot to keep straight.
The decisions are different in kind. Who sets the calendar and how quickly it updates, so the same slot is never sold twice. What happens when a provider cancels, and who rebooks the buyer. Whether the buyer pays in full at booking, pays a deposit, or pays after the work. When the provider is paid, and what happens to that payout if the buyer disputes the work. If the work produces something the buyer keeps using, such as images, there is also a question of rights and licensing.
Bookings, cancellations and payouts each need their own records here, because each changes at a different moment. A booking can be moved after it is paid, a payout can be held while a dispute is open, and a licence can outlive both.
Commission and what it is charged on
Every example above earns something from third-party sellers, and the decisions behind the stock, the payout and the credit decide what commission is charged on. A marketplace that stores and ships may charge for storage and handling as well as for the sale. A marketplace that holds funds until a service starts has to decide whether commission is taken at booking or at payout, and what happens to it on a cancellation. A marketplace that offers payment terms has to decide whether commission is earned when the order is placed or when the buyer finally pays.
For a smaller marketplace, the practical point is that commission has to be recorded per order line, with the rule that produced it. When a refund, a partial delivery or a late payment changes the order, the commission has to change with it, and the seller’s statement has to show why. If commission is worked out only at month end from totals, nobody can explain a single seller’s payout when they ask.
Multi vendor marketplace examples side by side
| Decision | Example | What it asks of a smaller marketplace |
|---|---|---|
| Marketplace stores and ships | Fulfillment by Amazon | Stock records per seller and location, reservations, receiving checks, returns to the right seller |
| Sellers ship their own orders | Many multi-vendor marketplaces at launch | Shipping updates from every seller, rules for late or missing shipments |
| Payout after the service starts | Airbnb host payouts | Held funds recorded per booking, cancellation rules, payouts triggered by event dates |
| Buyer pays later | Faire payment terms | Credit limits, invoices with due dates, receivables and seller payables matched per order |
| Selling time | Booking and service marketplaces | A calendar that never double-books, cancellation and rebooking rules, payouts tied to the work |
What your platform decides for you
Whatever you build on, some of these decisions are made before you start. A hosted marketplace platform usually comes with a payout schedule, a way of handling refunds and a set of seller permissions. If its defaults fit the decisions above, that is time saved. If your model depends on holding stock, paying on event dates or carrying buyer credit, check how far the defaults can be changed before you commit. The wider trade-off is set out in our comparison of custom vs SaaS marketplace builds, and if you are already on a hosted builder and hitting its limits, our guide to Sharetribe alternatives groups the options by the constraint you are hitting.
A custom build lets you set each rule yourself, from stock ownership to payout timing to credit. The cost of that freedom is that every rule has to be decided, built and run, and someone has to change it when the business changes. Neither path fits every marketplace. The examples above are most useful as a checklist: for each decision, write down which option you want, and what you would need to run it.
If you are weighing this for your own business, start with a plan. In two to three weeks we map how the system would connect to your ERP, warehouse, payments and sales channels, set out the build in phases with the cost to run it over three years, and give a fixed quote for the first phase. You keep the plan whatever you decide.