Multi-Vendor Marketplace Platform

Paid pluginsize XLplanned, not built

Indicative price, not an offer: EUR 1000-3000/year or EUR 5000-10000 one-off

Generated from docs/plan/paid/multi-vendor-marketplace-platform/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Paid platform that turns AstroBaaS into a multi-vendor marketplace. Vendors self-register, upload products, manage orders, and receive payouts. Operator controls commissions, disputes, and vendor approval. Includes vendor analytics and fulfillment workflow.

The problem

We want to become a marketplace with seller commissions but managing vendors is complex. Handling vendor onboarding, approvals, payouts, and disputes takes manual effort and custom code.

What it does

• Vendor self-registration with email verification and profile setup
• Vendor profile management (name, logo, description, contact info, tax ID)
• Vendor product upload (create/edit products in vendor’s catalog)
• Vendor visibility controls (publish/unpublish products)
• Product ownership enforcement (vendors see only their products)
• Commission calculation (per-vendor, per-product, or tiered by category)
• Commission types (fixed %, per-order fee, tiered thresholds)
• Vendor order view (see only orders for their products)
• Vendor fulfillment workflow (mark orders shipped, track fulfillment)
• Vendor payout system (scheduled payouts with commissions deducted)
• Payout reconciliation (itemized breakdown: orders, returns, fees)
• Dispute resolution workflow (customer disputes, operator investigates)
• Vendor performance metrics (products, orders, revenue, rating)
• Operator commission management (set, update, audit rates)
• Vendor analytics (orders per product, revenue, top sellers)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Automated payout processing to vendor bank accounts (reason: belongs to paid payment processor addon; core calculates and schedules only)
• Marketplace rating aggregation (reason: belongs to paid review system; core is operator-only ratings)
• Seller SLA/SLO enforcement (e.g., auto-suspend if response > 24h) (reason: legal complexity; belongs to support tier)
• White-label marketplace (reason: branding customization belongs to paid theming addon)
• Vendor approval via external KYC verification API (reason: belongs to paid compliance addon)

Data model

Migration required. New tables: vendors (name, email, approved, registration_date, commission_rate, status). vendors_bank_account (vendor_id, bank_name, account_encrypted, verified_at). New fields: products.vendor_id. orders.vendor_id (denormalized for fast query). order_items.vendor_id. New table: commissions (order_item_id, vendor_id, amount, status [pending/paid]). payouts (vendor_id, period_start, period_end, total_orders, total_commissions, status, payout_date). disputes (order_id, vendor_id, reason, status, resolution).

API

• POST /vendors/register
• GET /vendors/:id
• PATCH /vendors/:id
• POST /admin/vendors/:id/approve
• POST /admin/vendors/:id/suspend
• GET /admin/vendors
• POST /admin/vendors/:id/commission
• GET /admin/commissions
• POST /admin/payouts/schedule
• GET /admin/payouts
• POST /admin/disputes
• PATCH /admin/disputes/:id
• GET /vendors/me/products
• POST /vendors/me/products
• PATCH /vendors/me/products/:id
• GET /vendors/me/orders
• PATCH /vendors/me/orders/:id/fulfillment
• GET /vendors/me/payouts
• GET /vendors/me/analytics

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Vendor management dashboard (list, approve, suspend, set commissions). Vendor details (profile, metrics, payment info). Commission management (per vendor or category). Payout schedule and history. Dispute resolution queue (open disputes, evidence, resolution). Marketplace analytics (orders per vendor, revenue per vendor).

The seam — why this is paid

Core owns order management and fulfillment. Paid pack owns vendor isolation, commission calculation, and payout logic. Core creates orders; paid pack tracks vendor_id per order item and enforces access control. Core audit log tracks changes; paid pack logs vendor actions, commissions, and payouts.

Requires extensive support for vendor onboarding, commission automation, and dispute resolution. Highest support commitment.

Dependencies

• Core product catalog API (with vendor_id field)
• Core order creation and fulfillment API (with vendor_id tracking)
• Core customer and cart API (must work with vendor products)
• Existing authentication system (vendor login separate from operator)
• Payment system (for payout scheduling)
• Email system (vendor notifications)
• Storage system (vendor documents, dispute evidence)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A vendor registers, receives verification email, and can log in and create products
• Vendor products appear in storefront only after operator approves vendor
• A customer order with products from 2 vendors creates 2 order items, one per vendor
• Vendor A cannot see or edit Vendor B’s products
• Vendor A cannot see orders for Vendor B’s products
• Commission is calculated as (order_total - shipping - taxes) * commission_rate and appears in payout
• A payout is scheduled monthly with total orders, total commission, and payout amount
• A dispute is opened against a vendor; operator and vendor exchange evidence; resolution is logged
• Vendor login and admin login are separate sessions (no privilege escalation)

Risks

If vendor isolation is wrong, a vendor sees or edits other vendors’ products. If commission calculation includes refunded orders, vendor is paid for cancelled sales. If payout logic fails, vendors are not paid or are overpaid. If vendor authentication is weak, an attacker takes over a vendor account. If disputes are not tracked, merchants have no record for chargebacks. If a vendor is suspended mid-payout, they may or may not receive payment unfairly.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.