Multi-Vendor E-commerce Platform: Architecture and Key Components
A multi-vendor store is not a normal shop with extra user accounts. One cart can contain products from several sellers. One payment can become several fulfillments, several commissions, and several payouts. The architecture has to make those splits explicit or finance will do them in spreadsheets.
The Pieces That Must Exist
Storefront. What the buyer sees: search, product page, cart, checkout. It should not contain seller business rules.
Seller portal. Catalog upload, price, stock, order acceptance, shipping, and payout history for one vendor only.
Catalog. Products belong to a seller. Search can mix sellers, but inventory, price, and content stay owned by that seller.
Order service. The buyer has one order. Internally it splits into seller-level sub-orders (or fulfillments) so each vendor can ship their own lines.
Payments and payouts. The buyer pays the platform once. The platform later pays sellers, minus commission, fees, refunds, and reserves.
Admin. Onboarding, catalog moderation, disputes, commission plans, and the ability to suspend one seller without taking the marketplace down.
If any of these are “just a flag on the product table,” the second seller will expose the shortcut.
How One Checkout Becomes Many Shipments
Buyer cart (items from seller A and seller B)
↓
Single payment authorization
↓
Platform order created
↓
Sub-order A and sub-order B
↓
Each seller fulfills their sub-order
↓
Capture or release aligned to fulfillment policy
↓
Commission calculated per sub-order
↓
Seller payout on the settlement calendar
Decide early whether you capture the full amount at checkout or capture per seller when that seller ships. The choice changes refunds, cancellations, and what the buyer is told on the confirmation page.
Boundaries That Keep Sellers Apart
- A seller token can read and write only that seller’s products, orders, and payouts
- Stock decrement is per seller offer, not a global quantity on a shared SKU, unless you truly pool inventory
- A slow seller import cannot lock the catalog for everyone else
- Commission rules are data (plan, category, date range), not code copied per seller
- Files and images live in seller-scoped storage prefixes
Shared tables are fine. Shared authorization is not. Every query that sellers can trigger needs a seller id constraint that the seller cannot override.
Money Components People Forget
Commission. Percentage, flat fee, or both, sometimes by category. Store the rate used on the order line at purchase time. Do not look up “today’s rate” when you pay last month’s orders.
Refunds and returns. A refund reduces what the seller is owed. If you already paid them, the next payout carries a negative adjustment.
Shipping. Charged to the buyer, owed to the seller or to a platform logistics partner. Pick one model and show it on the sub-order.
Reserves. Holding a portion of payout for returns is a ledger rule, not a manual delay.
The ledger should be able to explain a payout as a list of sub-orders, fees, refunds, and reserves. If it cannot, the payout screen will generate support tickets.
Operational Surfaces
Buyers need honest ETAs when two sellers ship separately. Sellers need a queue of sub-orders, not a view of other vendors’ customers. Support needs a single order page that shows payment, each sub-order, and payout status together.
Catalog quality is a product function: required attributes, image rules, and a moderation state before an item is searchable. Unchecked seller content becomes your storefront.
Conclusion
Multi-vendor architecture is a split: one buyer experience, many seller fulfillments, and a ledger that can prove every payout. Design the sub-order and the commission snapshot first. The storefront is the easy part.
Connect With Us
At KIS Technology, we help businesses transform their ideas into secure and scalable digital solutions through software development, API integration, and quality engineering.
Build smarter. Build securely. Build for growth.
Connect with our Founder:
