Online marketplace development

A marketplace is a different business from a shop

A marketplace coordinates buyers, sellers, listings and transactions. Put plainly, you stop owning the stock and start owning the exchange, so what you are actually selling is trust, discovery and settlement rather than goods. Which responsibilities you carry and which stay with the seller is the first thing to scope, because every later argument traces back to it.

That shift changes the work more than most briefs allow for. Every listing is someone else's writing, every dispatch is someone else's promise, and every refund is a negotiation between three parties rather than a decision you make alone. Platform choice, catalogue structure, gateway fees and the shared order chain belong to e-commerce website development. This page covers what the marketplace layer adds on top.

Supply comes before demand, and it decides the build order

A marketplace is only as good as what is listed on it, so the seller side usually has to be built and filled first. Buyers who arrive to a thin catalogue do not come back to see whether it improved, and sellers who arrive to an empty platform have no reason to spend an afternoon uploading products. One side has to be worth joining before the other is invited.

In practice the first release leans towards supply: a way to apply, a way to load listings without typing them one at a time, category templates that make a small seller's data usable, and enough of a workspace that an order can be answered from a phone. The buyer storefront is visible, satisfying and comparatively quick to build. It is also useless in front of forty listings.

Deciding who may sell, and what stays up

Seller onboarding is a quality decision dressed up as a form. Somebody has to say who may trade, what must be true before a listing goes live, and what happens to a seller whose performance slips. Those rules are cheap to write now and expensive to introduce later, once sellers have built habits around their absence.

• Seller verification. Business details, the payout account and whatever your categories require, checked before the first listing rather than after the first complaint.
• Listing standards. Required attributes, image rules, prohibited items and the categories needing extra evidence, written as a checklist a reviewer can apply the same way twice.
• Performance measures. Late dispatch, seller cancellations, unanswered messages and dispute rates, shown to the seller in their own workspace rather than kept as a private score.
• A documented exit. How a seller is suspended, what happens to their open orders and pending payouts, and who signs that off.

Reviewing everything before publication stops being possible as a catalogue grows, and pretending otherwise produces a queue nobody clears. A workable position is layered: new sellers and restricted categories always reviewed, established sellers published immediately and sampled afterwards, and anything reportable by a buyer.

Commission, payouts and whose money it is

The question shaping most of the build is whether funds pass through your account on the way to the seller, or whether the payment is split and each side settled directly. The two produce different reconciliation and different holding periods. What is open to you depends on your gateway and on advice about operating a platform in your market that we are not the right people to give, so ask both in writing before the ledger is designed.

• The commission basis. A percentage per order line, a rate that varies by category, a listing fee, paid placement, or some combination. Each produces a different conversation with sellers.
• When commission is earned. At payment, at dispatch, or once the return window closes, and whether it reverses when an order is refunded.
• The payout schedule. How often payouts run, what hold period applies after delivery, and whether a new seller waits longer than an established one.
• Fee ownership. Who carries the gateway fee, the refund fee and the cost of a failed payout, agreed before a seller signs up rather than discovered on a statement.
• The statement itself. A payout a seller can rebuild from their own orders, with every deduction named, is the difference between a finance question and an argument.

Refunds after a payout need a decision of their own, because the money has already gone. A marketplace either absorbs that cost, recovers it from the next payout, or holds funds long enough to make it rare. All three are defensible, only one can be your rule, and it belongs in the seller agreement rather than a support reply.

One basket, several sellers

As soon as a buyer can put two sellers in one cart, the order stops being a single object. It becomes one payment and several fulfilment lines, each with its own dispatch, tracking and possible failure. Partial availability, partial cancellation and partial refund all follow from that, and each needs an agreed rule before a customer meets it.

The table works one fictional physical-goods marketplace through three of those moments. Every role, policy and response is an assumption made for illustration, and the last column lists evidence to collect in testing rather than results anybody has achieved.

Disputes are a product, not an inbox

Every marketplace eventually meets an order where the buyer says it never arrived, the seller says it did, and both are sincere. With no designed process that lands in a messaging app and is settled by whoever is most persistent. A dispute process is a small product: defined states, a clock on each one, evidence from both sides, a named decision-maker, and a liability rule written before anybody was angry.

Settle in advance who carries the cost in the three cases that make up most of the volume, which are not delivered, not as described, and damaged in transit. Then decide what evidence each requires, how long a buyer has to raise one, and what a dispute does to the seller's performance record. Make the outcome visible to both sides, because a ruling nobody can see reads as a ruling nobody made.

Which parts belong to other systems

Separating the marketplace layer from the systems underneath makes the scope easier to argue about. The cart, the payment attempt, the order record and the refund route are payment and checkout. Finding things in a catalogue nobody could scroll is catalogue and search. Seller workspaces, roles and permissions are accounts and portals, and when listings are time-based, such as stays or hire, the availability model comes from booking and scheduling.

Marketplace work is everything left: two-sided identity, the listing lifecycle, order splitting, commission and settlement, disputes, and the performance policy that keeps supply worth buying from.

What we have built, and how we would scope yours

We have built four marketplace prototypes to work these problems through rather than describe them. Aruva Marketplace is multi-vendor commerce with six role workspaces, following one order through buyer, seller, platform operations, the warehouse, the carrier and support. Dwellfound is a property marketplace. Voyaera is an accommodation marketplace with eight connected roles around a single reservation. Hire Creative is a two-sided event-services marketplace. All four are concept prototypes we built ourselves rather than client platforms, and no client outcome is implied by any of them.

Scoping runs in the same order as the build. Supply first: who may sell, what a listing must contain, who approves it. Then the money. The buyer journey comes last, and designs itself more easily once the two sides behind it are settled.

What to bring to a first conversation

Bring both sides as you would describe them to a friend: who sells, who buys and what each expects of the other. Bring how you intend to find the first sellers, what you plan to charge them and when, and anything already running that has to stay in step. Send that as a scoped enquiry and we will say which parts look ready to build and which need a policy decision from you first.