Marketplace Development: Multi-Vendor Commerce, Commissions, Moderation
Marketplace isn't a shop with multiple sellers. It's a platform where business logic centers on three sides: buyer, seller, platform. Each transaction touches all three. Error in commission calculation on 1000 orders per day — financial discrepancies impossible to untangle without separate reconciliation process.
Multi-Tenancy: How Vendor Data Divides
Two main data isolation models for vendors:
Shared database, shared schema — all vendors in same tables, each record has vendor_id. Cheaper infrastructure, simpler development. Risk: WHERE condition error — vendor sees others' orders. Must have Row Level Security (RLS) at PostgreSQL level or global scopes in ORM on all queries.
Shared database, separate schema (PostgreSQL schemas) — each vendor has own schema in one database. Stricter isolation, but trickier cross-vendor operations (platform stats, search all products).
For most marketplaces up to 10,000 vendors — shared schema with RLS. Separate schema — enterprise B2B with GDPR data isolation requirements.
Financial Mechanics: Commissions and Payouts
Commission calculation — most critical part where errors cost money.
First rule: never store commission as derivative, always as fact. On order creation fix: order sum, platform commission percentage at that moment, absolute commission value, sum for vendor payout. If you change commission rate tomorrow — historical orders stay with old numbers.
Commission models:
- Fixed percentage (5% per sale)
- Differentiated by category (electronics 3%, clothing 8%)
- Tiered by turnover (up to 100k — 10%, from 100k — 7%)
- Mixed: % + fixed per transaction
Stripe Connect — marketplace standard. Two modes: Destination charges (platform accepts payment, transfers to vendor) and Direct charges (payment goes directly to vendor, platform takes commission via application fee). Destination charges gives platform more control, including holds on disputes.
Vendor onboarding to Stripe Connect: KYC/AML check via Stripe Identity or built-in Stripe onboarding. Until vendor passes verification — payouts frozen. Thoughtful UX of this process critical for vendor conversion.
Escrow and holds. Money from buyer debits immediately, vendor transfers after delay (7–14 days) after delivery confirmation. Protects against fraud and enables holds on disputes. Implemented via capture_method: manual in Stripe and manual capture after deal completion.
Catalog with Multi-Vendor Products
One complex task: same product sold by multiple vendors. Two approaches:
Unified catalog (like Amazon): single product card, different vendors attached with offers at different prices and stock. Search and SEO by card, not offer. Complexity: who creates card, who's responsible, how resolve attribute conflicts from different vendors.
Per-vendor catalog (like Avito): each vendor maintains independent cards. Duplicates — norm. Simpler development and vendor relations, harder for buyer (comparing offers).
For niche B2B marketplace — per-vendor simpler and faster launch. For horizontal retail with many vendors — unified catalog gives better UX.
Real-time inventory. Two buyers simultaneously add last item to cart. Who buys? Optimistic locking on order creation: UPDATE inventory SET reserved = reserved + 1 WHERE product_id = ? AND (quantity - reserved) >= 1 — atomic operation, second request returns 0 affected rows, gets error "out of stock".
Content Moderation
Marketplace liable for vendor content. Typical issues: fake products, prohibited categories, price manipulation, fake reviews.
Moderation pipeline:
- Automatic checks on publish: required fields, category match, word restrictions (stoplist), image hash duplicates
- AI classification: category determination from text and image, prohibited content detection (Rekognition or Vertex AI Vision)
- Manual review queue for flagged products
Status machine for product: draft → pending_review → active / rejected → suspended. Each transition — event with reason and moderator. Vendor gets notification with specific rejection reason, not "rule violation".
Reviews: purchase verification mandatory (review only from user with confirmed order for product). Auto detector suspicious activity: sharp review spike from zero-history accounts — flag for manual check.
Dispute resolution: vendor and buyer can't self-resolve — platform arbitration. Time limits on each stage (buyer opens dispute within N days, vendor responds within M days). Stripe Disputes integration for auto chargeback response.
Search and Recommendations
Marketplace search with different vendors and hundreds thousands products — Elasticsearch or OpenSearch, not SQL LIKE. Vector search for semantics (see AI category), faceted filtering via Elasticsearch aggregations.
Personalized feed: clicks, purchases, views → collaborative filtering or content-based recommendations. A/B testing ranking algorithms mandatory — intuition bad advisor here.
Process
Marketplace — iterative development. MVP: vendor registration, product catalog, cart and checkout via Stripe Connect, basic moderation. After launch — real usage data determines next iteration priorities.
Typical order: MVP (3–4 months) → analytics and feedback → first extended release (2–3 months) → scaling and optimization.
Timeline
Marketplace MVP (catalog, checkout, basic vendor profiles): 3–5 months. Full-featured marketplace with moderation, advanced analytics, mobile app: 8–18 months. Adding marketplace functionality to existing e-commerce: 2–5 months.