Launch your multi-seller marketplace across buyer, seller and admin

The hard part of running a marketplace is not listing products; it is managing someone else's stock, shipping and money. One order splits across three sellers, one of them cancels, the buyer opens a return, and while the money sits with the payment provider it becomes unclear who is owed what. The whole thing works only when the buyer app, the seller app and the admin panel are built around the same logic from the start.

How many separate apps does this need?

  • 01

    Buyer app (iOS + Android)

    Category browsing and search, side-by-side comparison of different sellers offering the same product, seller ratings, multi-seller cart, order tracking, return requests and buyer-seller messaging screens.

  • 02

    Seller app (iOS + Android)

    Store onboarding and document upload, product entry, stock and price updates, new-order notifications, shipping label generation, return approval and payout balance visibility.

  • 03

    Admin panel (web)

    Seller application approval, product and content moderation, commission rate rules, payout and settlement periods, dispute resolution, category tree and campaign management.

What the app includes

  • Mandatory barcode match to a single catalog card
  • Offer list per product with default-seller ranking
  • Per-shipment tracking codes merged into one buyer view
  • Payout screen splitting held, pending and payable balances
  • Store vacation mode: listings visible, orders paused
  • Seller document expiry tracking with automatic suspension
  • Repeating audible new-order alert until the seller accepts
  • Variant-level stock with seller-specific variant pricing
  • Bulk percentage repricing with a floor-price warning
  • Rule set deciding who pays the return shipping cost
  • Campaign discounts funded by commission or by the seller
  • Seller scorecard: cancellation, late-dispatch and return rates

State of the sector

A new marketplace cannot compete with the large platforms on catalogue size; it makes room for itself in a specific category or region with better seller curation and lower commission. On the seller side the competition is blunt: the same seller is listed on three other platforms alongside yours and is looking at where products are easiest to upload. If products cannot be added from a mobile app, order notifications lag, or it is unclear when payouts land, the seller loses interest. On the buyer side, trust breaks the moment a return has to be sorted out over the phone, and the second order never comes.

Metrics that matter here

  • Time from seller sign-up to first order — If product entry and approval steps drag on after registration, the seller disappears; the app shortens those steps on mobile
  • Seller-caused cancellation rate — Stock synchronisation and reservation at the moment of ordering directly reduce orders that are sold and then cancelled
  • On-time dispatch rate — Instant order notifications for sellers and one-tap shipping labels affect delivery times and buyer complaints
  • Search-to-product-page conversion — If product matching and filter quality are poor, buyers get stuck in the results list and never reach the cart

Common mistakes in this sector

  • Trying to turn single-seller e-commerce software into a marketplace It starts by bolting a seller module onto off-the-shelf store software; with no cart splitting, per-seller shipping or payout tables, every order needs manual reconciliation. Once order volume grows, the system gets rewritten from scratch.
  • Leaving the seller app for later The buyer app is built first and seller management is left to a web panel. Small sellers are not at a computer during the day, so orders are seen late, shipments are delayed and the cancellation rate climbs. The seller side belongs in the first release.
  • Hard-coding commission A single fixed rate gets written into the code; once category-based rates, campaign discounts or seller-specific deals are needed, every change requires a new release. Commission should be designed from the start as a rule set managed from the panel.
  • Allowing free-form listings with no product matching Every seller enters the same product under their own title, search results fill up with duplicate cards and buyers cannot compare prices. If barcodes or category templates are not made mandatory at the start, thousands of records have to be cleaned up later.

Regulation and compliance

A company operating a marketplace is treated as an e-commerce intermediary service provider under Law No. 6563 on the Regulation of Electronic Commerce: this brings ETBIS registration (Turkey's official e-commerce registry), verification and publication of seller identity and contact details, takedown of content upon complaint, and — depending on transaction volume — licensing obligations. The Distance Contracts Regulation also places liability on the intermediary in certain cases. On payments you cannot hold the money yourself; under Law No. 6493 a sub-merchant model must be set up through a licensed payment institution. You also need KVKK (Turkey's data protection law, aligned with GDPR) disclosure notices and retention rules for both buyer and seller data, plus e-Fatura/e-Arşiv (Turkey's mandatory e-invoicing system) for commission revenue.

The real challenges in this sector

  • One cart splitting into multiple orders

    A buyer adds items from three different sellers and pays once; behind the scenes three separate orders, three shipments and three payout lines are created. Shipping costs have to be calculated per seller, and if one order is cancelled the others must stay intact. The cart model has to be built around shipment-level orders from day one, with a reconciliation table that distributes the single payment across those parts.

  • You cannot hold the money: the sub-merchant model

    A marketplace cannot park a seller's money in its own bank account; that counts as providing payment services. The correct setup is to register each seller as a sub-merchant with a licensed provider such as iyzico (a Turkish payment provider) or Craftgate, collect payments already split, and release the payout through that provider once delivery is confirmed. If the app is not designed around this flow, it has to be torn apart and rewritten later.

  • Stock synchronisation and the same product sold in two places

    Most sellers list the same product simultaneously on their own site and on other marketplaces. If stock is decremented late, an order is accepted and then cancelled, and ratings drop. You need XML/CSV feeds and webhook-based stock decrements working together, stock reserved at the moment of ordering, and sellers automatically removed from listings after repeated cancellations.

  • What happens when 30 sellers list the same product

    Without barcode or product-code matching, one phone model becomes thirty separate listings and search results turn into noise. Products must be bound to a single listing with sellers shown as offers, and the default seller picked by a score combining price, delivery time and cancellation rate. The rules behind that score have to be shown to sellers transparently.

  • Returns, disputes and shipments stuck in limbo

    When a buyer opens a return, the product goes back to the seller while the money sits in the balance held at the payment provider. You need a flow that blocks the payout until the dispute is settled, generates the return shipping label and decides automatically when the deadline passes. Otherwise every dispute ends up being handled over WhatsApp and distance-selling obligations cannot be evidenced.

Required integrations

  • Split payments and payout transfers via iyzico Marketplace / Craftgate sub-merchant accounts
  • Yurtiçi, Aras, MNG and PTT (Turkish courier companies) APIs for per-seller contracted shipping and return labels
  • e-Arşiv commission invoices through a GİB (Turkish Revenue Administration) integrator, plus seller invoice upload checks
  • ETBIS notifications and verification of seller tax and MERSİS (Turkish central trade registry) details
  • Turkish-language search with synonyms and typo tolerance via Elasticsearch or Typesense
  • XML/CSV product feeds and stock synchronisation with the seller's existing e-commerce platform

Who this page is for

  • A startup building a niche marketplace in a single category

    A narrow product range with sellers approved by hand. Catalog templates and barcode matching belong in the first release; the campaign engine and API can wait. Phase one launches with one category.

  • A wholesaler or manufacturer digitizing its dealer network

    Buyers are registered dealers, so dealer codes and credit limits replace open signup. Prices vary by customer group and payment is often on terms. The weight sits on ERP integration and order approval flows, not public search.

  • A local marketplace bringing neighbourhood shops together

    Same-day courier or click-and-collect replaces carriers, with delivery zones and time windows defined per seller. Products are added by photo from the phone and catalog matching can stay loose. What matters is stock accuracy and the delivery slot.

A phased plan that splits the budget

  1. 1

    Phase 1 — A working marketplace in one category 6-8 hafta

    Buyer and seller apps, manually approved seller onboarding, photo-based product entry, a multi-seller cart and split payment through sub-merchant accounts at a licensed payment institution. Returns and disputes are handled manually in the panel at this stage. Money flow must be right on day one, otherwise everything built on top of it gets torn down.

  2. 2

    Phase 2 — Seller scale-up and automation 5-7 hafta

    XML/CSV product feeds, stock reservation at order time, two carrier integrations, return label generation, payout hold rules and automatic resolution when a dispute deadline passes. Manual steps break down as the seller count grows, and automation is only designed correctly once real order flow has been observed.

  3. 3

    Phase 3 — Catalog quality, campaigns and API 4-6 hafta

    Barcode-matched catalog cards, default-seller scoring, improved Turkish-language search, commission rules per category and seller, campaign funding split, and API sync for sellers running their own e-commerce stack. These only pay off once the catalog passes a certain size; built earlier they sit empty.

Typical scope and timeline

Typical scope: native iOS and Android apps for both buyers and sellers, an admin panel, product and category template structure, multi-seller cart and order splitting, sub-merchant and payout flows with a licensed payment institution, integration with two courier companies, return and dispute management, e-Arşiv commission invoicing, search infrastructure, KVKK documentation, store assets and the release process.

Estimated timeline: 14-22 weeks

Off-the-shelf or custom build?

Topic Off-the-shelf Custom build
Time to launch A packaged marketplace runs within days: seller signup, cart and commission accounting come out of the box. Genuinely a good way to test your first sellers and category. Custom development takes weeks to reach a first release. In exchange, order splitting, payouts and returns follow your own business model.
Payments and seller payouts A package works with the payment institution it is bundled with. Rules such as hold periods, partial refunds or releasing payout after cash-on-delivery collection usually cannot be changed. The sub-merchant model, hold periods and dispute-time fund retention are written to your decisions, and survive a change of payment provider.
Cost structure A monthly subscription, often plus a share of transaction volume. Cheap while volume is low; as it grows, it permanently eats into your own commission margin. A one-off build, then hosting and maintenance. Heavier at the start, but no platform share as transaction volume grows.
Catalog data and moving seller relationships Product, seller and order data can be exported, but catalog matches, seller score history and payout records are usually embedded in the platform's own schema. The database is yours: catalog matches, seller agreements and historical payout records move intact and can be shown at source during an audit.

Sector glossary

Take rate
The share of transaction volume the platform keeps. In a marketplace it is never one number: it varies by category, seller agreement and campaign funding, so it is managed as rules in the admin panel.
Buy box (default seller)
Among the sellers listing the same product, the one shown behind the add-to-cart button. Selection usually combines price, dispatch time and cancellation rate, and sellers expect that rule to be transparent.
Order split (shipment)
The sub-order a single buyer cart is split into per seller. Each part carries its own tracking code, delivery status, return window and payout line; cancellations and returns operate at that level.
Held balance
Money from a completed sale not yet transferred to the seller, waiting on delivery confirmation, the end of the return window or the close of a dispute. The seller app should show the date it is expected to release.
Catalog matching
Tying the same product, entered by different sellers, to a single card via barcode or product code. Weak matching fills search results with duplicate cards and makes price comparison impossible for the buyer.

Frequently asked questions

Let us talk about your project

A free 30-minute call to scope it out, then an itemised quote within 48 hours.

Get a Free Quote

This page explains the problems an app must solve in this sector. We share references and comparable projects during the call.

Other sectors

All sectors →