Jai Shree Krishna! 🙏
Yes—your intuition is correct. A serious e-commerce marketplace is not a website with products + cart + payment gateway. It is closer to an operating system for commerce connecting:
Customers ↔ Sellers ↔ Marketplace ↔ Payments ↔ Logistics ↔ Support ↔ Administrators
Webkul's marketplace material reflects this: marketplace functionality adds vendor registration/approval, seller dashboards, vendor catalogs, commissions, shipping/taxes, messaging, reviews, reporting and marketplace administration on top of ordinary e-commerce. (Webkul Software)
The best mental model is:
Build the marketplace-specific brain yourself. Rent commodity infrastructure from SaaS providers.
For example, you build your rules for orders, sellers, commissions and fulfillment. Razorpay/Cashfree moves money, Shiprocket interacts with courier networks, Resend sends emails, MSG91/Twilio sends messages, Cloudinary stores/transforms media, and Freshdesk manages support.
A normal e-commerce store usually looks like:
Store
↓
Products
↓
Customer
↓
Cart
↓
Checkout
↓
Payment
↓
Order
↓
Warehouse
↓
Shipping
There is one merchant.
A marketplace changes this considerably:
MARKETPLACE
SELLER A SELLER B SELLER C
│ │ │
└──────────────┬──────┴──────────────┬──────┘
│ │
Vendor Management
│
Product Catalogue
│
Marketplace
Storefront
│
Buyer
│
Cart
│
Checkout
│
Payment
│
┌──────────┼───────────┐
│ │ │
Order A Order B Order C
│ │ │
Seller A Seller B Seller C
│ │ │
Shipment Shipment Shipment
│ │ │
└──────────┴─────┬─────┘
│
Delivery
│
Seller Settlement
That seller dimension infects almost every commerce problem.
You now have to answer:
- Who owns this product?
- Who may edit it?
- Who approves it?
- Who owns inventory?
- Which seller receives the order?
- Who ships the item?
- What commission applies?
- Who receives the money?
- When does the seller get paid?
- What happens when one seller's item is cancelled?
- What happens when one seller ships but another does not?
- Who bears a refund?
- Who handles return shipping?
- Who answers the customer's complaint?
- What can admins override?
Those are marketplace problems, not UI problems.
A good marketplace generally contains three major user-facing systems.
Home
Search
Categories
Product pages
Seller pages
Cart
Checkout
Payments
Orders
Tracking
Returns
Reviews
Account
Support
Seller registration
KYC
Seller profile/store
Product management
Inventory
Pricing
Orders
Shipping
Returns
Earnings
Settlements
Analytics
Reviews
Support
Users
Sellers
Seller verification
Products
Moderation
Orders
Payments
Commissions
Settlements
Returns
Refunds
Disputes
Shipping
Support
Promotions
Reports
Fraud
Configuration
Audit logs
These three applications operate on the same commerce platform underneath.
Your six modules are the correct starting point, but a production marketplace decomposes further.
I would organize it into roughly nine domains.
Responsible for:
- registration
- login
- OTP/email verification
- password reset
- sessions
- refresh tokens
- OAuth
- MFA
Actors could include:
Customer
Seller
Seller employee
Support agent
Moderator
Operations employee
Finance employee
Super Admin
Owns:
Customer
CustomerProfile
Address
Preferences
SavedAddresses
Devices
Used by:
Cart
Checkout
Orders
Reviews
Returns
Notifications
One of the most important marketplace modules.
Owns:
Vendor
VendorUser
VendorProfile
VendorAddress
VendorBankAccount
VendorDocuments
KYCStatus
VendorStatus
VendorPermissions
Lifecycle:
REGISTERED
↓
KYC_PENDING
↓
UNDER_REVIEW
↓
APPROVED
↓
ACTIVE
or
REJECTED
SUSPENDED
BLOCKED
Webkul similarly describes marketplace vendor registration followed by marketplace approval before sellers start managing products. (Webkul Software)
Cashfree's marketplace payment documentation also illustrates why seller onboarding and KYC cannot be an afterthought: its vendor workflow includes bank/UPI details and KYC documentation before settlement. (Cashfree)
Example:
Fashion
├─ Men
│ ├─ Shirts
│ ├─ T-Shirts
│ └─ Jackets
│
├─ Women
│ ├─ Dresses
│ ├─ Kurtis
│ └─ Sarees
│
└─ Accessories
├─ Bags
└─ Jewellery
Categories should normally be marketplace-controlled rather than freely invented by every seller.
This is considerably more complicated than:
Product
name
price
image
A more realistic structure is:
Vendor
↓
Product
├─ Category
├─ Brand
├─ Description
├─ Attributes
├─ Media
├─ Variants
├─ Pricing
└─ Inventory
Example:
Product:
Nike Running Shoe
Variants:
Size 8 / Black
Size 9 / Black
Size 10 / White
Possible entities:
products
product_variants
categories
attributes
attribute_values
product_attributes
product_images
product_documents
brands
tags
And critically:
product.vendor_id
This one relationship turns normal commerce into marketplace commerce.
Do not allow seller listings to automatically become public unless that matches your business model.
Typical lifecycle:
Seller creates product
DRAFT
↓
SUBMITTED
↓
UNDER_REVIEW
↓
APPROVED
↓
PUBLISHED
Possible alternative:
REJECTED
CHANGES_REQUIRED
SUSPENDED
The marketplace admin therefore remains in control of marketplace quality.
Owns:
available_quantity
reserved_quantity
sold_quantity
warehouse
inventory_movements
Important distinction:
10 available
Customer begins checkout
→ reserve 1
Available = 9
Reserved = 1
Payment succeeds
→ reserved becomes sold
Otherwise two people can purchase the last item simultaneously.
Don't make your transactional database responsible for sophisticated search forever.
Conceptually:
Catalog Database
│
│ ProductPublished
↓
Search Index
↓
Customer search
Capabilities eventually include:
- full-text search
- autocomplete
- filters
- facets
- typo tolerance
- sorting
- ranking
- synonyms
- category navigation
Potential services:
- Algolia
- Typesense
- Meilisearch
- Elasticsearch/OpenSearch
For an early MVP, even PostgreSQL search can be enough.
Separate product media from the product domain.
Seller uploads image
↓
Media Service
↓
Virus/type validation
↓
Object storage
↓
Image processing
↓
CDN
↓
Product stores media URL/reference
Options:
- Cloudinary
- Amazon S3 + CloudFront
- Cloudflare R2
- ImageKit
Don't store binary images directly in PostgreSQL.
Typical structure:
Cart
├─ Item A → Seller A
├─ Item B → Seller A
├─ Item C → Seller B
└─ Item D → Seller C
The seller relationship becomes essential at checkout.
Price calculations usually combine:
Base product price
+
Variant price
-
Promotion
+
Tax
+
Shipping
=
Final price
The pricing module should own the calculation.
Not React.
Not the database query.
Not the payment gateway.
Eventually:
Marketplace coupon
Seller coupon
Product discount
Category promotion
Minimum order discount
First-purchase discount
Free shipping
You must also decide:
Who funds the discount?
Marketplace?
Seller?
Both?
This affects settlement accounting.
Checkout is an orchestration module.
It coordinates:
Cart
Customer
Address
Inventory
Pricing
Promotion
Tax
Shipping
Payment
Order
Conceptually:
POST /checkout
1. Validate customer
2. Validate cart
3. Validate prices
4. Validate inventory
5. Reserve inventory
6. Determine shipping
7. Calculate taxes
8. Calculate total
9. Create payment order
10. Customer pays
11. Verify payment
12. Create marketplace order
Checkout therefore should not own all those capabilities. It coordinates other modules.
This is arguably the heart of the marketplace.
Suppose a buyer purchases:
Seller A:
T-shirt
Cap
Seller B:
Shoes
Seller C:
Wallet
Don't model this merely as one flat order.
Use something like:
Marketplace Order #1001
│
├── Vendor Order #1001-A
│ Seller A
│ ├─ T-shirt
│ └─ Cap
│
├── Vendor Order #1001-B
│ Seller B
│ └─ Shoes
│
└── Vendor Order #1001-C
Seller C
└─ Wallet
Medusa's official marketplace recipe demonstrates exactly this marketplace-specific requirement: customer orders containing multiple vendors can be split into separate vendor orders while retaining vendor associations. (Medusa Docs)
This is a major architectural idea.
Imagine:
Seller A → ships today
Seller B → cancels
Seller C → ships tomorrow
Your overall marketplace order isn't simply:
SHIPPED
Each seller fulfillment has its own lifecycle.
Order 1001
Vendor A → SHIPPED
Vendor B → CANCELLED
Vendor C → PROCESSING
The buyer UI can then construct the overall status.
Never model an order using random booleans like:
paid = true
shipped = false
cancelled = false
Use proper states.
For example:
CREATED
↓
PAYMENT_PENDING
↓
CONFIRMED
↓
PROCESSING
↓
READY_TO_SHIP
↓
SHIPPED
↓
OUT_FOR_DELIVERY
↓
DELIVERED
And alternative flows:
CANCELLED
RETURN_REQUESTED
RETURNED
REFUNDED
DISPUTED
This is where marketplaces become much harder than normal stores.
You actually need several separate modules:
Payment Processing
Commission Engine
Vendor Ledger
Settlement
Payout
Refund
Reconciliation
Do not collapse them all into one payments table.
Your system should not store raw card details.
Use a payment provider such as:
- Razorpay
- Cashfree
- PayU
- PhonePe Payment Gateway
- Stripe
- Adyen
- PayPal/Braintree
But a marketplace needs more than ordinary checkout payments.
It needs:
Buyer
↓
Marketplace payment
↓
Commission calculation
↓
Vendor share
↓
Settlement
↓
Vendor bank account
Razorpay's Route product specifically supports linked seller accounts, payment transfers, settlement management, refunds/reversals and reconciliation for marketplace-style one-to-many money flows. (Razorpay)
Cashfree has a similar marketplace product called Easy Split, covering:
- vendor onboarding
- commission deduction
- order-level splits
- settlement
- vendor balances
- refunds
- reconciliation. (Cashfree)
Internationally, Stripe Connect provides the same general class of marketplace capabilities through connected accounts, charges/transfers and payouts where its relevant flows are supported. (Stripe Docs)
As of August 2026, Razorpay's Route documentation states that access is subject to updated RBI-related eligibility requirements. Its current documentation specifies, among other things, minimum turnover requirements and payer-payee transparency. (Razorpay)
This matters enormously for a brand-new startup.
You therefore shouldn't design the system assuming:
"We'll definitely use Razorpay Route."
Instead:
Payment Module
│
PaymentProvider
│
┌────────────┴─────────────┐
│ │
Razorpay Adapter Cashfree Adapter
Keep provider-specific code behind an adapter.
Commission is your business logic.
Examples:
Marketplace-wide:
10%
Category:
Jewellery → 12%
Apparel → 8%
Seller-specific:
Premium seller → 6%
Product-specific:
Featured product → 15%
Conceptually:
CommissionEngine.calculate(orderItem)
returns something like:
grossAmount
sellerShare
marketplaceCommission
paymentFee
taxOnCommission
discountContribution
shippingContribution
netSellerPayable
Store this calculation as a historical snapshot.
If you change commission from 10% to 12% tomorrow, yesterday's orders must not magically change.
This deserves its own module.
Example:
Vendor Ledger
ORDER_EARNING +X
COMMISSION -X
SHIPPING_FEE -X
REFUND -X
ADJUSTMENT +X
PAYOUT -X
The balance is calculated from ledger entries.
Don't merely ask Razorpay:
"How much money do I owe Seller A?"
Your marketplace should maintain its own auditable accounting state and reconcile it with the payment provider.
Payment and settlement are different.
Customer pays
↓
Payment succeeds
↓
Order is fulfilled
↓
Return/dispute window/business condition
↓
Seller amount becomes payable
↓
Settlement provider
↓
Seller's bank
Depending on your marketplace rules and provider capabilities, seller payment may occur sooner or later.
You need to compare:
Our Order Ledger
↕
Payment Gateway Transactions
↕
Vendor Settlements
↕
Bank Statements
Cashfree, for example, exposes vendor reconciliation, settlement, transaction and refund reporting specifically for such workflows. (Cashfree)
Finance systems should never depend entirely on "the webhook probably worked."
Break logistics into separate concerns:
Fulfillment
Shipment
Courier Selection
Pickup
Label/AWB
Tracking
Delivery
Return Shipping
For India, one common architecture is:
Your Marketplace
↓
Shipping Aggregator
↓
┌────┼───────────────┐
│ │ │
DTDC Delhivery Xpressbees ...
Shiprocket's API, for example, exposes courier serviceability, courier selection, AWB assignment, pickup and return-order operations across multiple courier providers. (Shiprocket API)
Your code can therefore say:
ShippingProvider.createShipment()
ShippingProvider.generateAWB()
ShippingProvider.requestPickup()
ShippingProvider.trackShipment()
instead of implementing separate courier logic everywhere.
Order confirmed
↓
Vendor prepares package
↓
Shipment created
↓
Courier serviceability check
↓
Courier selected
↓
AWB generated
↓
Pickup requested
↓
PICKED_UP
↓
IN_TRANSIT
↓
OUT_FOR_DELIVERY
↓
DELIVERED
Courier updates normally arrive through:
Webhook
↓
Shipping Integration
↓
Shipment Module
↓
Order Module
↓
Notification Module
Notice that the courier does not directly modify your order database.
Most beginners stop designing at:
Order delivered
Real commerce continues.
You need:
Return Request
Eligibility
Seller/Admin approval
Reverse pickup
Inspection
Return received
Refund Request
↓
Refund calculation
↓
Payment Gateway
↓
Gateway webhook
↓
Refund confirmed
↓
Vendor ledger adjustment
Customer complaint
Seller response
Evidence
Admin arbitration
Resolution
Only permit legitimate reviews according to your marketplace rules, commonly after a valid purchase/delivery.
Webkul also identifies seller/product ratings and reviews as core marketplace functionality. (Webkul Software)
Other modules shouldn't directly contain code such as:
sendEmail(...)
sendSMS(...)
sendWhatsApp(...)Instead:
Order Module
↓
OrderShipped Event
↓
Notification Service
↓
┌──────┬───────┬──────────┐
Email SMS WhatsApp Push
Email services:
- Resend
- SendGrid
- Amazon SES
- Postmark
Resend exposes transactional email APIs and even supports idempotency keys for duplicate prevention. (Resend)
SMS:
- MSG91
- Twilio
- Gupshup
Twilio exposes messaging functionality through its Programmable Messaging APIs. (Twilio)
Instead of building an entire support product initially, integrate:
- Freshdesk
- Zendesk
- Intercom
- Zoho Desk
For example, Freshdesk supports customer conversations across channels such as email, chat and voice through a unified support environment. (Freshworks)
Your marketplace can associate tickets with:
customer_id
vendor_id
order_id
shipment_id
payment_id
This is far more useful than an isolated "Contact us" inbox.
The admin panel isn't merely CRUD screens.
It is effectively the operating system for your marketplace.
You need areas like:
Dashboard
Customers
├─ Search
├─ Suspend
└─ History
Vendors
├─ Applications
├─ KYC
├─ Approvals
├─ Suspension
└─ Performance
Catalog
├─ Products
├─ Categories
├─ Attributes
└─ Moderation
Orders
Payments
Vendor earnings
Settlements
Refunds
Returns
Disputes
Shipping
Reviews
Promotions
Support
Analytics
Platform settings
Audit logs
CS-Cart describes a similar operational scope in its multi-vendor product: centralized vendor management, approval workflows, dedicated seller dashboards, catalog controls, permissions, performance, commissions, vendor payouts and split payments. (www.cs-cart.com/)
Several system-wide services aren't visible to customers but become critical.
Who changed what
Before value
After value
Timestamp
IP/device
Reason
Especially important for:
- seller suspension
- refunds
- payouts
- commission edits
- order overrides
Turn capabilities on/off without redeploying.
For:
abandoned carts
settlement jobs
reminders
expired offers
cleanup
reports
Receive events from:
Payment provider
Shipping provider
KYC provider
Communication provider
Don't sprinkle external APIs throughout business code.
Use:
PaymentProvider
ShippingProvider
EmailProvider
SMSProvider
StorageProvider
SearchProvider
KYCProvider
with provider-specific adapters.
A sensible first architecture looks like this:
┌───────────────────┐
│ CUSTOMER WEB/APP │
└─────────┬─────────┘
│
┌───────────────────┐
│ VENDOR PORTAL │
└─────────┬─────────┘
│
┌───────────────────┐
│ ADMIN PANEL │
└─────────┬─────────┘
│
▼
┌───────────────────────┐
│ API / APPLICATION │
│ LAYER │
└───────────┬───────────┘
│
┌─────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Identity │ │ Customer │ │ Vendor │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Catalog │ │ Inventory │ │ Search │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Pricing │ │ Cart │ │ Checkout │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Orders │ │ Payments │ │ Commission │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Ledger │ │ Settlement │ │ Refund │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Fulfillment │ │ Shipping │ │ Tracking │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Returns │ │ Reviews │ │ Support │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│Notification │ │ Analytics │ │ Admin │
└──────────────┘ └──────────────┘ └──────────────┘
│
▼
┌────────────────────────┐
│ INTEGRATION LAYER │
└──────────┬─────────────┘
│
┌──────────┬───────┼──────┬───────────┐
▼ ▼ ▼ ▼ ▼
Payment Shipping Email SMS/WA KYC
SaaS SaaS SaaS SaaS SaaS
There are two primary mechanisms.
When an immediate answer is required:
Checkout
↓
Inventory
↓
"Is stock available?"
YES / NO
Typically REST/HTTP or internal function/module calls.
When another activity can happen afterward:
Order
↓
OrderConfirmed
↓
Event Queue
├─ Notification
├─ Analytics
├─ Search
├─ Seller dashboard
└─ Fulfillment
This makes systems more resilient.
Medusa's documentation similarly describes commerce automation as listening to domain events and performing asynchronous operations instead of tightly coupling every operation. (Medusa Docs)
This deserves emphasis.
A diagram like:
30 Microservices
Kafka
Kubernetes
Service Mesh
Multiple databases
Distributed tracing
looks impressive.
It is usually a terrible starting point for a first marketplace.
Instead build:
Marketplace Backend
src/
├─ auth/
├─ customers/
├─ vendors/
├─ catalog/
├─ inventory/
├─ search/
├─ cart/
├─ checkout/
├─ orders/
├─ payments/
├─ commissions/
├─ settlements/
├─ shipping/
├─ returns/
├─ refunds/
├─ reviews/
├─ notifications/
├─ admin/
└─ analytics/
One deployable application.
One main PostgreSQL database.
But strong module boundaries.
Later:
Modular Monolith
↓ scale pressure
Search → separate service
Notifications → separate worker
Payments → isolated service
Orders → separate service
Analytics → event pipeline
AWS demonstrates independently scalable commerce modules in more advanced microservices/serverless architectures, but that pattern is solving scaling and operational concerns that a first MVP generally doesn't yet have. (Amazon Web Services, Inc.)
For a modern TypeScript-first marketplace:
| Layer | Suggested technology |
|---|---|
| Customer web | Next.js + React |
| Vendor portal | Next.js |
| Admin portal | Next.js |
| Language | TypeScript |
| Styling | Tailwind CSS |
| Backend | NestJS |
| API | REST/OpenAPI initially |
| Primary DB | PostgreSQL |
| ORM | Prisma / Drizzle / TypeORM |
| Cache | Redis |
| Background jobs | BullMQ |
| Search MVP | PostgreSQL |
| Search later | Algolia / Typesense / OpenSearch |
| Media | Cloudinary or S3 |
| Object storage | Amazon S3 / R2 |
| Queue later | SQS / RabbitMQ |
| CDN | CloudFront / Cloudflare |
| Container | Docker |
| Monitoring | Sentry + OpenTelemetry |
| CI/CD | GitHub Actions |
| Infrastructure | AWS / GCP / Azure |
| Frontend hosting | Vercel or CloudFront |
| Backend early | managed container/server |
| Backend scale | ECS/Fargate / Kubernetes if genuinely necessary |
Medusa itself uses a Node-based commerce backend and offers a Next.js starter storefront, showing that this general TypeScript/headless model is a viable modern commerce approach. (Medusa Docs)
Use PostgreSQL as your transactional source of truth.
Roughly:
PostgreSQL
│
├── Identity
│
├── Users
│
├── Vendors
│
├── Products
│
├── Inventory
│
├── Carts
│
├── Orders
│
├── Payments
│
├── Commissions
│
├── Ledger
│
├── Shipments
│
├── Returns
│
└── Reviews
Then use specialized stores for specialized jobs:
PostgreSQL → transactional truth
Redis → cache / sessions / jobs / locks
Search engine → search index
S3/Cloudinary → media
Analytics system → analytical events
Don't try to use one database technology for every job.
Here is the broader answer to your SaaS question.
| Requirement | Build or Buy? | Examples |
|---|---|---|
| Authentication | Either | Auth0, Clerk, Cognito |
| KYC | Buy | Cashfree Verification, Signzy, Digio |
| Payments | Buy | Razorpay, Cashfree |
| Marketplace settlement | Buy | Razorpay Route, Cashfree Easy Split |
| Shipping | Buy | Shiprocket, NimbusPost, direct Delhivery |
| Buy | Resend, SES, SendGrid | |
| SMS | Buy | MSG91, Twilio |
| Buy/API | Gupshup, MSG91, Meta | |
| Media | Buy | Cloudinary, ImageKit |
| Object storage | Buy | S3, Cloudflare R2 |
| Search | Buy/self-host | Algolia, Typesense |
| Customer support | Buy | Freshdesk, Zendesk, Intercom |
| Analytics | Buy | PostHog, Mixpanel, GA4 |
| Error monitoring | Buy | Sentry |
| Maps/address | Buy | Google Maps, Mapbox |
| Tax/GST | Buy/integrate | ClearTax etc. |
| Fraud/risk | Buy | payment-provider tooling |
| CDN/WAF | Buy | Cloudflare, CloudFront |
| Accounting | Integrate | Zoho Books, Tally ecosystem |
Because these differentiate your marketplace:
Marketplace rules
Vendor model
Vendor permissions
Catalog ownership
Product approval rules
Order orchestration
Vendor-order splitting
Commission rules
Internal settlement ledger
Fulfillment rules
Return rules
Dispute workflows
Admin operations
Marketplace-specific UX
Payment rail
Bank transfers
SMS network
Email infrastructure
Courier network
KYC verification
Image CDN
Cloud infrastructure
Helpdesk
Monitoring
Don't spend six months building an email delivery platform.
It gives your marketplace essentially zero competitive advantage.
Now connect everything.
Seller signs up
↓
Authentication
↓
Vendor profile
↓
Business/KYC documents
↓
Bank details
↓
KYC provider
↓
Admin verification
↓
APPROVED
↓
Seller activated
Seller dashboard
↓
Create product
↓
Upload media
↓
Set variants
↓
Set inventory
↓
Assign category
↓
Submit product
↓
Admin moderation
↓
Approved
↓
Catalog publishes product
↓
Search indexing
↓
Product becomes discoverable
Customer visits marketplace
↓
Browse/search
↓
Search engine
↓
Product results
↓
Product page
↓
Seller information
↓
Reviews
↓
Add to cart
Cart
Product A → Seller 1
Product B → Seller 1
Product C → Seller 2
↓
Checkout
↓
Address
↓
Inventory check
↓
Price verification
↓
Promotion calculation
↓
Shipping calculation
↓
Tax calculation
↓
Final amount
↓
Payment
Never trust the browser saying:
paymentSuccess=true
Instead:
Customer
↓
Payment Provider
↓
Provider verifies payment
↓
Webhook
↓
Marketplace Backend
↓
Verify webhook signature
↓
Payment = SUCCESS
↓
Create/confirm Order
Webhooks must also be idempotent so retrying the same event does not create duplicate orders.
Master Order #1001
↓
Order Service
↓
Group lines by seller
↓
┌────────────┬────────────┐
▼ ▼ ▼
Seller A Seller B Seller C
Order Order Order
Then:
Seller A sees only Seller A items.
Seller B sees only Seller B items.
Seller C sees only Seller C items.
This is why role-based access and seller ownership are fundamental.
Seller receives order
↓
Accepts/prepares
↓
Package ready
↓
Marketplace calls shipping API
↓
AWB created
↓
Pickup scheduled
↓
Courier collects package
↓
Tracking events
↓
Customer notified
↓
Delivered
Payment successful
↓
Seller earning recorded
↓
Commission recorded
↓
Order delivered / settlement rule satisfied
↓
Seller payable
↓
Marketplace payment provider
↓
Vendor settlement
↓
Bank
↓
Provider webhook
↓
Ledger marked settled
The whole system can now be visualized as:
SELLER
│
▼
Vendor Management
│
▼
KYC
│
▼
Catalog
│
├──→ Media
├──→ Inventory
└──→ Search
│
▼
CUSTOMER
│
▼
Cart
│
▼
Checkout
│
┌──────┼────────┐
▼ ▼ ▼
Inventory Pricing Shipping
│ │ │
└──────┼────────┘
▼
Payment
│
▼
Order
│
▼
Vendor Order Split
│
┌─────┴─────┐
▼ ▼
Seller A Seller B
│ │
▼ ▼
Shipment Shipment
│ │
└─────┬─────┘
▼
Delivery
│
▼
Settlement
│
┌───┴────┐
▼ ▼
Commission Vendor
Marketplace Payout
That is the core marketplace machine.
Don't write:
OrderService
├── calls Razorpay directly
├── calls Shiprocket directly
├── calls Twilio directly
└── calls Cloudinary directly
Better:
Order Service
│
▼
Payment Service
│
▼
PaymentProvider Interface
│
├── RazorpayProvider
└── CashfreeProvider
Likewise:
ShippingProvider
├── ShiprocketAdapter
└── DelhiveryAdapter
NotificationProvider
├── ResendAdapter
├── MSG91Adapter
└── WhatsAppAdapter
Changing SaaS vendors becomes much easier.
Imagine OrderDelivered.
Don't write:
OrderDelivered()
{
updateOrder();
sendEmail();
sendSMS();
createSettlement();
updateAnalytics();
askForReview();
updateSellerStats();
}
Now your Order service knows everything.
Instead:
Order Service
│
▼
OrderDelivered
│
▼
Event Bus
│
┌───┼────────┬──────────┬─────────┐
▼ ▼ ▼ ▼ ▼
Email SMS Settlement Analytics Reviews
Far cleaner.
You don't initially need this:
40 servers
Kubernetes
Kafka cluster
10 databases
service mesh
Start here:
INTERNET
│
Cloudflare/CDN
│
┌─────────────┴─────────────┐
│ │
Next.js NestJS API
│ │
│ ┌────────┼─────────┐
│ │ │ │
│ PostgreSQL Redis Worker
│ │
│ Background Jobs
│
└──────────────────────────────────┐
│
External SaaS Integrations
│
┌──────────┬─────────┬─────────┬─────┴──────┐
▼ ▼ ▼ ▼ ▼
Payments Shipping Email SMS Media
This can go surprisingly far.
Only after actual scale:
API Gateway
│
┌──────────────┼─────────────┐
│ │ │
Catalog Order Payment
Service Service Service
│ │ │
└──────────────┼─────────────┘
│
Event Bus
│
┌─────────┬───────┼──────┬─────────┐
▼ ▼ ▼ ▼ ▼
Inventory Shipping Notify Settlement Analytics
AWS's architecture guidance describes this advantage: individual commerce modules such as product search and order submission can be independently deployed and scaled. (Amazon Web Services, Inc.)
But independent scalability is something you graduate into, not something you need to imitate on day one.
You also asked for methods other than building everything yourself.
There are several.
Example:
Sharetribe
It currently supports building physical-product marketplace flows without coding, including seller listings, inventory, buyers, transactions and shipping/pickup-oriented flows. Sharetribe itself recommends this style for getting an initial marketplace live quickly enough to validate before investing heavily in customization. (Sharetribe)
Validation
Prototype
Very early marketplace
Simple transaction workflow
Custom business logic eventually becomes limiting.
Architecture:
Shopify
+
Webkul MultiVendor
or other marketplace applications.
Webkul's current Shopify app provides seller dashboards, commissions, seller listings, automated payout-related functionality and marketplace extensions. (Shopify App Store)
Another current option is Shipturtle, which focuses on seller onboarding, catalogs, order routing, shipment/tracking and payouts. (Shopify App Store)
Standard marketplace:
Products
Cart
Checkout
Sellers
Orders
Shipping
Your transaction model differs radically from traditional ecommerce.
Architecture:
WordPress
+
WooCommerce
+
Multi-vendor plugin
Examples include:
- Dokan
- WCFM
- Webkul
Cheap.
Large ecosystem.
Fast setup.
Complex marketplace customization can become plugin-dependent and difficult to maintain.
Examples:
- CS-Cart Multi-Vendor
- Sharetribe
- other marketplace-focused suites
CS-Cart already includes vendor onboarding, seller dashboards, permissions, products, commissions, payouts and marketplace operations. (www.cs-cart.com/)
You configure more and build less.
For example:
Bagisto
Bagisto is an open-source Laravel-based commerce platform that can be extended into a multi-vendor marketplace. (Bagisto)
Good when:
You want code ownership
but
don't want to build commerce fundamentals from zero.
This is an interesting middle ground.
Example:
Next.js
↓
Medusa
↓
Custom Marketplace Modules
Medusa explicitly documents this approach.
Its marketplace recipe adds:
Vendors
Vendor admins
Vendor-product relationships
Vendor-order relationships
Vendor APIs
Vendor dashboards
Multi-vendor order splitting
on top of its existing commerce functionality. (Medusa Docs)
This gives you considerable flexibility without rebuilding absolutely every commerce primitive.
You build:
Frontend
Backend
Database
Marketplace engine
Admin
Seller dashboard
Integration layer
while still outsourcing infrastructure such as payments/logistics/KYC.
Maximum control.
Perfect fit for unusual marketplace workflows.
Own architecture and business logic.
Most engineering.
Most testing.
Most operational responsibility.
| Method | Speed | Customization | Engineering | Long-term control |
|---|---|---|---|---|
| Sharetribe/no-code | ★★★★★ | ★★ | ★ | ★★ |
| Shopify + marketplace app | ★★★★★ | ★★★ | ★★ | ★★ |
| WooCommerce + plugins | ★★★★ | ★★★ | ★★ | ★★★ |
| CS-Cart | ★★★★ | ★★★ | ★★ | ★★★ |
| Bagisto | ★★★ | ★★★★ | ★★★ | ★★★★ |
| Medusa + custom marketplace | ★★★ | ★★★★★ | ★★★★ | ★★★★★ |
| Fully custom modular monolith | ★★ | ★★★★★ | ★★★★★ | ★★★★★ |
| Custom microservices | ★ | ★★★★★ | ★★★★★★ | ★★★★★ |
That last row isn't a typo: microservices can create more engineering complexity than a young marketplace actually needs.
Don't begin by asking:
"What database? What programming language? Should I use Kafka?"
Begin with:
Document:
Who are sellers?
Who are buyers?
Who owns inventory?
Who sets prices?
Who ships?
Who handles returns?
Who is responsible for refunds?
How much commission?
When are vendors paid?
What happens during disputes?
Who approves sellers?
Who approves products?
Until these answers exist, architecture cannot be correct.
Document the state machines before the UI.
registration → KYC → approval → active
draft → review → approved → published
created → paid → processing → shipped → delivered
initiated → pending → success/failed → refunded
pending → payable → processing → settled/failed
requested → approved → picked-up → received → refunded
These state machines are your marketplace's real blueprint.
Think in relationships:
User
↓
Vendor
↓
Product
↓
Variant
↓
Inventory
Customer
↓
Cart
↓
CartItem
↓
Order
↓
VendorOrder
↓
OrderItem
Order
↓
Payment
↓
Commission
↓
VendorLedger
↓
Settlement
VendorOrder
↓
Shipment
↓
TrackingEvent
Initial implementation order:
1. Authentication
2. Customer
3. Vendor
4. Admin vendor approval
5. Categories
6. Products
7. Product moderation
8. Inventory
9. Storefront
10. Search/basic filtering
11. Cart
12. Checkout
13. Payment
14. Order
15. Seller order dashboard
16. Shipping
17. Tracking
18. Commission
19. Vendor ledger
20. Settlement
21. Notifications
22. Returns/refunds
23. Reviews
24. Support
Then connect:
Payment → Razorpay/Cashfree
Marketplace payout
→ provider-supported marketplace product
Shipping → Shiprocket
Email → Resend
SMS/OTP → MSG91
WhatsApp → provider API
Media → Cloudinary/S3
Support → Freshdesk
Monitoring → Sentry
Analytics → PostHog
Before scaling features, add:
Idempotency
Database transactions
Webhook signature verification
Retries
Dead-letter jobs
Rate limiting
RBAC
Audit logs
Backups
Monitoring
Structured logging
Error tracking
Reconciliation jobs
Those features make the difference between:
"website"
and
commerce infrastructure.
Avoid:
Microservices everywhere
Kafka
Kubernetes
Custom payment processing
Custom SMS infrastructure
Custom courier network software
AI recommendation engine
Complex Elasticsearch cluster
Event sourcing everywhere
Blockchain
Multiple databases per module
Premature multi-region infrastructure
None of those things will make sellers join or buyers purchase.
There are ultimately four types of components:
┌──────────────────────────────────────┐
│ 1. MARKETPLACE BUSINESS LOGIC │
│ │
│ Vendor rules │
│ Catalog ownership │
│ Commissions │
│ Orders │
│ Settlements │
│ Returns │
│ Disputes │
│ │
│ BUILD │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│ 2. COMMODITY INFRASTRUCTURE │
│ │
│ Payments │
│ Shipping │
│ Email │
│ SMS │
│ KYC │
│ Storage │
│ Customer support │
│ │
│ BUY │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│ 3. PLATFORM INFRASTRUCTURE │
│ │
│ PostgreSQL │
│ Redis │
│ CDN │
│ Queue │
│ Monitoring │
│ Cloud hosting │
│ │
│ OPERATE │
└──────────────────────────────────────┘
┌──────────────────────────────────────┐
│ 4. USER EXPERIENCES │
│ │
│ Customer storefront │
│ Vendor dashboard │
│ Admin panel │
│ Mobile apps │
│ │
│ DESIGN │
└──────────────────────────────────────┘
That is probably the simplest complete mental model of marketplace engineering.
A normal product marketplace is mostly:
Discovery
→ Cart
→ Checkout
→ Payment
→ Order
→ Shipment
→ Delivery
But that architecture is only a base commerce engine.
If your marketplace involves:
Request
Negotiation
Quotation
Seller acceptance
Partial/advance payment
Production
Customization
Quality checking
Milestone/status tracking
then those should become additional first-class modules between product discovery and the traditional order/payment lifecycle.
Webkul itself illustrates this distinction in its B2B marketplace functionality, where RFQs, negotiation, quotation, purchase orders and approvals extend traditional e-commerce workflows. (Webkul Software)
So you should never blindly copy Amazon's transaction model just because Amazon is a marketplace.
The business workflow determines the architecture.
If I reduce this whole answer to one system:
MARKETPLACE PLATFORM
│
┌──────────────────────────┼──────────────────────────┐
│ │ │
CUSTOMER SELLER ADMIN
│ │ │
└──────────────────────────┼──────────────────────────┘
│
MARKETPLACE BACKEND
│
┌──────────┬─────────┬──────┼───────┬──────────┐
│ │ │ │ │ │
Catalog Cart Order Payment Shipping Settlement
│ │ │ │ │ │
└──────────┴─────────┴──────┼───────┴──────────┘
│
INTEGRATION LAYER
│
┌─────────┬─────────┬──────┼─────┬────────────┐
│ │ │ │ │ │
Payments Logistics KYC Email SMS Support
Your application owns commerce state and marketplace rules. External SaaS providers execute specialized infrastructure functions. PostgreSQL keeps transactional truth. Events connect workflows. Admins operate the system. Sellers fulfill orders. Customers interact with one unified storefront.
That is how a serious e-commerce marketplace fits together.