Multi vendor marketplace development in Saudi Arabia, built around your commission model

What is multi vendor marketplace development in Saudi Arabia, and when do you need it?

Multi vendor marketplace development in Saudi Arabia means building one platform where many independent sellers list goods or services, buyers pay in one checkout, and the platform owner earns a commission or fee. It is a different product from an online store, because you are running a small economy: sellers, buyers, money in the middle and rules for all three.

You need a marketplace when your value is the network, not the stock. A few patterns fit it well in the Kingdom: regional food and dates sellers who could never afford their own store, B2B supply platforms where contractors order from many wholesalers, services marketplaces for tutors, cleaners or event suppliers, and niche platforms such as oud and perfume makers or specialty coffee roasters.

You probably do not need one if you hold the inventory yourself, or if you only have two or three suppliers. A normal store with supplier drop-shipping is cheaper to run. The same goes for a directory: if buyers pay sellers outside the platform, you need listings and lead forms, not split payouts and vendor ledgers.

• Commission marketplace: you take a percentage of each sale; the most common model.
• Subscription marketplace: vendors pay a monthly fee to list; easier accounting, slower growth.
• Lead marketplace: buyers request quotes and vendors pay per lead; no checkout at all.
• Hybrid: a small listing fee plus a lower commission, common for B2B platforms.

Pick the model before any design work. It decides the database, the payment flow and the invoice logic, and changing it after launch is the most expensive rework a marketplace can have.

How does vendor onboarding work with CR and VAT numbers?

Vendor onboarding is a short, bilingual application form backed by an approval queue. Each seller enters business details, uploads documents, and waits for you to approve them before a single product goes live. Getting this right is what keeps the marketplace clean when vendor number 200 signs up.

For a Saudi seller the useful fields are the commercial registration (CR) number, the VAT registration number if they have one, the legal name as it appears on the CR, the national address, a contact person, and an IBAN for payouts. Freelancers and home businesses may hold a freelance document or a different licence instead of a CR, so we make the document type a choice rather than a hard rule.

Checking the numbers can be manual or automated. Manual means your team looks each vendor up and ticks a box. Automated means calling a verification service: Wathq, a Saudi data platform, offers commercial registration and national address data through APIs under its own subscription terms. We build the call and store only what you need from the response.

How do commission and split payments work through Saudi payment gateways?

There are two ways to move money in a multi vendor marketplace: let the gateway split each payment at settlement, or collect everything into your account and pay vendors out on a schedule. Both work in Saudi Arabia; the choice depends on what your gateway offers and what your lawyer says about holding sellers' money.

With gateway split settlement, each vendor is registered as a sub-merchant or split recipient with your gateway. At checkout the platform tells the gateway how much goes to whom, and your commission never touches the vendor's share. It is cleaner, but every vendor must pass the gateway's own checks before they can sell.

With collect-then-pay-out, the full amount lands in your merchant account and the platform keeps a ledger of what each vendor is owed. Payouts run weekly or after the return window closes. Onboarding is faster, but you are handling other people's money, so ask your legal adviser whether that needs a licence or specific terms in your vendor agreement.

• Shoppers pay with mada, credit cards and Apple Pay; mada is the national payment system owned and operated by the Saudi Central Bank.
• Commission can be a percentage, a fixed fee per order, or tiered by monthly volume.
• Refunds claw back both the vendor's share and, if your policy says so, your commission.
• Every movement is written to a ledger row, so any payout can be traced back to its orders.

We integrate the gateway you sign with; we do not resell gateway accounts or take a cut of payments.

Who issues the ZATCA e-invoice when a marketplace sells for a vendor?

It depends on how your marketplace is structured, and your tax adviser must decide it before we build. In one model each VAT-registered vendor issues its own e-invoice to the buyer. In another the platform issues the invoice on the vendor's behalf. ZATCA's own guidance says the e-invoicing rules apply to taxpayers and also to parties issuing tax invoices on behalf of VAT-registered suppliers.

Your commission is a separate supply: you invoice the vendor for your fee, and that invoice is yours to issue. So even the simplest marketplace produces two invoice streams, one for the goods and one for the service you sell to sellers.

Per ZATCA's e-invoicing overview, the generation phase began on 4 December 2021 and the integration phase began on 1 January 2023, rolled out in waves. For a marketplace that means invoice data has to be structured, not a PDF template, and it has to be traceable to the seller who made the supply.

What should a Saudi marketplace disclose under the E-Commerce Law?

Saudi Arabia's E-Commerce Law, published by the Ministry of Commerce, sets duties for anyone selling online, and a marketplace carries them for its own service and helps vendors meet theirs. Your lawyer should confirm the exact list; our job is to make sure every required detail has a field, a place on the page and an owner.

In practice that usually means three layers of disclosure. The platform shows who runs it, how to contact you, and its terms. Each vendor page shows who the seller actually is, so a buyer knows whom they are buying from. Each product page shows the price with VAT, delivery terms and the return policy that applies to that seller.

Because vendors write their own listings, the build also needs moderation. We add required fields that cannot be skipped, a review step for new listings, and a report button so buyers can flag misleading products. Policy text itself comes from you and your lawyer.

• Platform identity and contact details in the footer and on a dedicated page.
• Seller name and registration details on every vendor profile and product page.
• VAT-inclusive prices, delivery fees and delivery time shown before payment.
• Return and cancellation terms per vendor, accepted by the buyer at checkout.
• Order confirmation by email or WhatsApp with the seller's identity attached.

Salla, Zid or a custom build for a multi vendor marketplace in Saudi Arabia?

Choose a hosted platform with a multi-seller add-on to test demand cheaply; choose a custom build when commissions, payouts or invoices follow your own rules. Salla and Zid are designed around one merchant selling its own catalogue, so marketplace behaviour usually comes from an app or custom code sitting on top.

The hosted route wins on launch speed, built-in local payments and shipping, and no server to look after. It loses when vendors need their own dashboards, when payouts must be automated per seller, or when invoices must carry each vendor's VAT details. At that point you spend more working around the platform than building on it.

A custom marketplace gives you the data model: vendors, commission rules, ledgers and invoice streams as first-class objects. It costs more up front and you take on hosting, but nothing about your business rules is limited by someone else's roadmap. Our Salla developer page and Zid developer page cover what each platform can do if you stay hosted.

Which tech stack suits a multi vendor marketplace?

A boring, well-known stack is the right answer for most Saudi marketplaces. We usually propose a TypeScript or PHP backend with a relational database such as PostgreSQL, a server-rendered storefront for speed and search visibility, and Flutter for apps. Money and ledger data belong in a relational database with transactions, not in a document store.

Search matters more in a marketplace than in a store, because buyers compare many sellers. A dedicated search engine handles Arabic text, typo tolerance, filters by city and price, and ranking by vendor rating. Background jobs handle payouts, invoice generation and notifications, so the checkout stays fast even on busy nights.

Hosting location is your decision. Some clients want data held inside the Kingdom; Google Cloud, for example, runs a Dammam region, which per Google Cloud's documentation KSA-based customers access through its local partner. Others host in a nearby region. Read our PDPL website compliance guide before you choose.

• Storefront: server-rendered pages with Arabic and English routes and proper hreflang.
• Backend: REST or GraphQL API shared by the website, vendor dashboard and apps.
• Database: PostgreSQL or MySQL with strict foreign keys around orders and ledgers.
• Apps: Flutter for Android and iOS, published under your own developer accounts.

How much does multi vendor marketplace development in Saudi Arabia cost?

With us, a custom marketplace starts from US$900, a lighter build on an ecommerce base starts from US$750, and apps start from US$600. Those are starting points; the itemised quote reflects your rules. Quotes elsewhere vary widely, and the gap is mostly explained by the drivers below rather than by hourly rates.

The single biggest driver is payouts. Manual payouts, where your finance team exports a report and pays vendors by bank transfer, are cheap to build. Automated split settlement with refunds, holds and clawbacks is a real piece of software. The second driver is invoicing: generating per-vendor invoice data and connecting it to an e-invoicing solution adds scope that a single-merchant store never needs.

After that come the number of dashboards (buyer, vendor, admin, maybe a finance role), whether you want apps at launch or later, the number of languages, and how much catalogue moderation you want automated.

• Payout model: manual export, scheduled batch, or gateway split settlement.
• Commission logic: one rate, per-category rates, or tiers and promotions.
• Invoice streams: vendor-issued, platform-issued on behalf, plus commission invoices.
• Catalogue type: physical goods, services with booking, or B2B with quotes.
• Apps: web only, buyer app, vendor app, or both.

Ask us to price a phase-one scope and a full scope side by side. Most marketplaces launch faster, and spend less, by leaving automated payouts or the vendor app for phase two.

How long does it take to launch a marketplace, and what belongs in version one?

A first release takes 6–12 weeks for a custom build and 4–8 weeks for a store-based version. The fastest launches are the ones that ruthlessly cut version one down to the loop that proves the business: a vendor signs up, lists, sells, and gets paid correctly.

Everything else can follow. Loyalty points, vendor advertising, live chat, coupons stacked across sellers and fancy analytics are all good ideas for month four. None of them matter if vendors leave because payouts are wrong.

• Weeks 1–2: model, commission rules, payout flow and invoice decision written down and signed off.
• Weeks 2–4: vendor onboarding, approval queue and catalogue with moderation.
• Weeks 4–7: checkout, gateway integration, order splitting and vendor notifications.
• Weeks 7–9: ledger, payouts, refunds and invoice data per vendor.
• Weeks 9–12: Arabic content, testing with real vendors, soft launch and fixes.

Invite five to ten friendly vendors into a closed pilot before opening sign-ups. They find the confusing parts of onboarding in days, and their feedback is cheaper than any redesign after launch.

Building an Arabic-first catalogue that sellers can fill in themselves

A Saudi marketplace should default to Arabic, mirror its layout for right-to-left reading, and offer English as a switch. The hard part is not the storefront; it is the vendor tools. If adding a product in Arabic and English is painful, sellers will fill in one language badly and your catalogue will look half-finished.

We give vendors paired fields for title and description, clear rules on which are required, and a preview of both versions. Categories, attributes and filters are translated once by you, so sellers only choose values. Arabic search needs normalisation, so a search for a word with or without certain letter forms still finds the product.

We write English and build bilingual interfaces; the Arabic interface text and policies are supplied or approved by you. For deeper detail on layout mirroring, fonts and URLs in both languages, see Arabic–English website development.

• Right-to-left layouts with icons and progress bars mirrored correctly.
• Numbers, prices and dates shown the way your customers expect.
• Separate Arabic and English URLs so each version can rank.
• Vendor emails and WhatsApp messages sent in the seller's chosen language.

How do you handle reviews, returns and disputes between buyers and vendors?

You design trust as a workflow, not a page. Buyers need to see real ratings, sellers need a fair way to answer complaints, and you need a clear rule for who pays when something goes wrong. The software enforces those rules; you write them.

Reviews should come only from verified orders, and vendors should be able to reply publicly once. A return request opens a case with a timer: the vendor accepts or responds, and if they do not, the case escalates to your staff. Money for that order stays on hold in the ledger until the case closes, so you never pay a vendor for an order you later refund.

Vendor performance scores help you act before buyers complain. Late shipping, high cancellation and frequent returns are easy to count, and the admin dashboard can flag sellers who cross a threshold you set.

SEO and AI-search visibility for a Saudi marketplace

Marketplaces can rank well because they have many pages, and they can also sink under thousands of thin, duplicate listings. The build decides which one you get. Category pages, vendor pages and strong product pages should be indexable; filtered combinations and near-empty listings should not.

When several vendors sell the same item, pick one canonical product page with multiple offers rather than ten near-identical pages. Product structured data with offers and ratings helps search engines understand the page. Core Web Vitals matter too: a marketplace home page with dozens of vendor images needs lazy loading and image resizing from day one.

AI assistants answer shopping questions by quoting clear, factual pages. Vendor pages with a short, specific description, shipping areas and return terms, plus category guides written by you, are what those systems can cite. Monthly SEO from US$150/mo covers content and technical checks after launch, and our SEO services for Saudi Arabia page explains what that includes. Nobody can guarantee rankings; a clean structure gives you the best chance.

• Index: categories, vendor profiles, products with real content.
• Noindex or canonicalise: filter combinations, sort orders, out-of-stock duplicates.
• Submit Arabic and English sitemaps in Google Search Console.
• Watch crawl stats as vendor numbers grow.

Personal data in a marketplace: what vendors should and should not see

A marketplace passes customer data to third parties by design, so it needs tighter data rules than a normal store. A vendor needs a delivery address and phone number to fulfil an order. They do not need the buyer's email, order history with other sellers or payment details.

We scope vendor access to the minimum: the order, the delivery details, and only until delivery is complete. After that, the vendor dashboard can mask the address and phone number. Buyer–vendor messages run through the platform, so contact details are not traded outside it. Admin access is split by role, and every export is logged.

Saudi Arabia's Personal Data Protection Law applies to this processing, and SDAIA publishes the law and its implementing regulations. Our separate page on PDPL compliance for websites covers privacy notices, consent and breach logging in depth. Your lawyer confirms the legal side; we build the controls.

• Vendor sees: order items, delivery name, address and phone, for a limited period.
• Vendor never sees: buyer email, payment data, other vendors' orders.
• Platform keeps: an audit log of every access and export.
• Vendor agreement: data-handling terms drafted by your lawyer.

Working with a team in India on your marketplace, from Saudi Arabia

Working with us from the Kingdom is straightforward because the hours line up. India is two and a half hours ahead of Saudi time, so a 10 a.m. call in Riyadh is 12:30 p.m. for us, and most of your Sunday-to-Thursday working day overlaps with ours. We also reply on WhatsApp on Fridays and Saturdays, since we answer messages seven days a week.

Calls happen on Google Meet or Zoom, with a written summary afterwards. Quotes are in US dollars, which convert predictably because the riyal is pegged to the dollar, and payments go by Wise or bank wire. Invoices come from India. There is no Saudi office and no site visits; everything, including vendor training, happens on video.

You own the domain, hosting, gateway account, app store accounts and code from the start. We work inside accounts you create and hand over admin access at the end, not the other way round.

Worked example: a hypothetical specialty coffee marketplace

Say a founder in Riyadh wants a marketplace for independent coffee roasters across the Kingdom, starting with twenty roasters and a commission on each bag sold. This is a hypothetical scenario to show how the decisions play out, not a past project.

Onboarding asks each roaster for CR, VAT number if registered, IBAN and national address, plus roast-date rules for listings. The founder's accountant decides each VAT-registered roaster issues its own invoice, and the platform invoices roasters monthly for commission. That decision alone shapes the order data.

For payments, the founder's gateway supports split settlement, but some roasters are slow to pass its checks. So phase one uses collect-then-pay-out with a weekly payout after a seven-day return window, and phase two moves verified roasters to split settlement. Baskets with bags from three roasters create three shipments with separate tracking.

Version one launches as a web marketplace with Arabic and English, a vendor dashboard that works on a phone, and a WhatsApp alert for each new order. The buyer app waits until repeat purchases prove demand. The build is quoted from US$900, with the app from US$600 as a later phase.

Handover, red flags and a launch checklist for your marketplace

At handover you get the code repository, deployment notes, admin credentials rotated to your team, a data dictionary for orders and ledgers, and a recorded walkthrough of vendor approval, payouts and dispute handling. Two months of free maintenance follow, then support from US$120/mo if you want it.

Be wary of any developer who cannot explain where the money sits between checkout and payout, who proposes storing card data themselves, or who treats invoicing as "just a PDF". Those are the three places marketplaces fail audits and lose vendor trust.

• Marketplace model, commission rules and payout schedule written and signed off.
• Accountant's written answer on who issues each invoice.
• Gateway contract signed, with marketplace or split features confirmed.
• Vendor agreement, buyer terms, return policy and privacy notice approved by your lawyer.
• Five pilot vendors onboarded and paid out once in testing.
• Refund, dispute and bank-detail change flows tested end to end.
• Arabic and English sitemaps submitted; analytics and consent banner live.