A single-vendor store and a multi-vendor marketplace look similar in a wireframe. They are not the same system. Adding a vendor dimension changes the shape of the order, the money, and the permission model all at once, and the cost of retrofitting it later is most of a rebuild.
One order, many fulfilments
The moment a basket can contain items from two vendors, the order stops being a single unit of state. Each vendor ships on their own schedule, from their own location, with their own courier and their own cancellation. An order status column cannot express this.
Model the order as a parent with per-vendor sub-orders from the first commit. Every status, shipment, refund and notification hangs off the sub-order. The parent exists for the customer's view of their purchase and nothing else.
Money is the part that bites
Customers pay once. Vendors get paid separately, minus commission, on a payout schedule, in the presence of partial refunds and chargebacks that may arrive weeks later. If commission is calculated at payout time from live data, a price change rewrites history.
Snapshot the commercial terms onto the line item at checkout — commission rate, tax treatment, vendor identity. The record of what was agreed must be immutable even when the configuration behind it changes.
- Write a ledger, not a balance. Every movement is an append-only entry; the balance is derived.
- Reconcile against the payment provider on a schedule and alert on drift, however small.
- Handle the refund-after-payout case explicitly. It will happen in the first quarter.
Every query is vendor-scoped
Vendor A must never see vendor B's orders, customers, margins or stock. That constraint touches every endpoint, every report and every export — and it is the single most common place we find security holes when auditing an existing marketplace.
Enforce it at the data-access layer rather than in each controller. A scoping rule applied in one place is auditable; the same rule repeated across ninety endpoints is a matter of time.
The unglamorous work that decides the outcome
Vendor onboarding, catalogue moderation, bulk imports of inconsistent spreadsheets, dispute handling. None of it demos well and all of it determines whether the platform is usable at a hundred vendors.
We budget for the operations tooling in the first phase. Marketplaces that treat the admin panel as a phase-two concern end up running on manual database edits, and that habit is very hard to reverse.
