Key Components of a Seller Cabinet and Storefront
We develop storefront and seller cabinet for marketplace. Poor interface means a week-long onboarding, a flood of support tickets, and supplier churn. Our team creates modules that cut product listing time to 2 hours (down by 70%) and order processing to minutes. Typical pains: sellers spend hours filling out cards, don't see actual stock, and lose orders in statuses. Our solution is a module with dynamic forms, materialized metrics, and API for delivery service integration. For a DIY segment client, we built a cabinet where the seller uploads 500+ products in 15 minutes via an Excel template with validation, reducing time-to-listing by 80%. This solution reduced manual listing costs by $3,000 per month and increased conversion by 20%, leading to an additional $5,000 monthly revenue for average sellers. This article covers architecture, key sections, mass import, live-metrics dashboard, order processing, access rights, and development timelines. Get a ready roadmap for module implementation. Request a consultation — we'll evaluate your project for free.
How Is the Seller Cabinet Architecture Structured?
The seller cabinet is a separate SPA or a set of pages isolated from the buyer-facing part. It operates within the same codebase (Laravel/Node.js) but through a separate middleware stack that checks the seller role and binds to shop_id. Sections: dashboard with metrics (revenue, orders, conversion, rating), product management (create, edit, mass import via Excel/CSV), order management (statuses, tracking, labels), finances (balance, payout history), store settings (description, logo, return policies).
Seller Storefront (Public Page)
The public storefront is /shop/{slug} with a product selection, seller info, and a rating block. It's server-rendered for SEO. Includes aggregated data: average rating, review count, buyout percentage. Filtering and search within the store, a subscribe button, and a recent reviews block with seller responses.
How to Implement Mass Product Import Without Downtime?
The product creation form is a complex component with dependent fields. Attribute sets change by category: for electronics — warranty and specs, for clothing — size chart and composition. Implemented via a dynamic attribute schema stored in the database:
category_attributes (category_id, attribute_name, type, required, options)
product_attribute_values (product_id, attribute_id, value)
Mass import uses a queue: the file is uploaded to S3, a job parses it row by row, creates products and photos. An error report is returned to the seller via email or in the UI. This guarantees no locks and the ability to process hundreds of products in minutes. This reduces listing time by 80% compared to manual entry.
Dashboard — Real-Time Metrics
Dashboard data is not built on the fly — too expensive. We use materialization: the seller_stats table is updated hourly via a scheduled job. Current-day data is computed live via Redis counters. Charts are built from order_daily_aggregates — pre-aggregated daily data. For visualization we use Recharts or Chart.js. The dashboard component fetches data via a separate API endpoint, not mixed with main CRUD. Our dashboard has reduced decision-making time by 40% for sellers.
| Metric |
Source |
Update |
| Revenue |
order_daily_aggregates |
Hourly |
| Orders today |
Redis |
Live |
| Conversion |
seller_stats |
Hourly |
| Rating |
DB (aggregated) |
Live |
Order Processing by Seller
The seller sees only orders containing their products. Processing interface:
- Confirm order (status
confirmed, notify buyer).
- Transfer to delivery: enter tracking number or call delivery service API.
- Mark shipped: status
shipped, automatic email to buyer.
- Handle returns: return request from buyer → seller decision → financial operation.
Each status transition is logged in order_status_history with timestamps and actor_id.
Access Rights Inside the Cabinet
A large seller may have a team. Needs a role system within the store:
| Role |
Products |
Orders |
Finances |
Settings |
| Owner |
R/W |
R/W |
R/W |
R/W |
| Manager |
R/W |
R/W |
R |
— |
| Warehouse |
R |
R/W |
— |
— |
Implemented via Laravel Authorization with tenant-scope: each role is bound to shop_id.
Tech Stack and Timelines
Backend: Laravel with Eloquent, Gate/Policy policies, queues on Redis/Horizon.
Frontend: React with React Hook Form, TanStack Query, Shadcn/ui components.
File storage: S3 (MinIO for self-hosted), presigned URL generation for direct browser upload.
Basic cabinet (products + orders + dashboard without complex analytics) — 3–4 weeks. Full module with mass import, team roles, and financial section — 6–8 weeks.
What's Included
- Analytics and architecture design.
- Implementation of all cabinet sections.
- Mass product import.
- Role and permissions system.
- Delivery service integration.
- Testing (unit, integration, e2e).
- Deployment and infrastructure setup.
- Documentation and team training.
- Post-launch support.
Our team has 5+ years of experience in marketplace development and over 10 successful projects. Our solution is 30% faster than typical templates thanks to Server Components and caching. Contact us to get a consultation and project estimate.
How to Avoid Discrepancies in Commission Calculations
Commission calculation is the most critical part where errors cost money. Rule one: never store commission as a derived value, always as a fact. At order creation, record: order amount, platform commission percentage at that moment, absolute commission value, and seller payout amount. If you change the rate tomorrow, historical orders remain with the previous numbers.
Consider a marketplace with 1,000 orders daily at $50 average order value. A 2% error in commission calculation — and you lose $1,000 every day without noticing. Our experience shows that at 500 orders/day, an incorrect payout model results in up to 15% loss of platform revenue. We have solved this for 50+ projects, from niche B2B to horizontal retail. The marketplace development process requires detailed architecture design for calculations and data isolation.
Commission Models (we use one of or combine)
| Model |
Principle |
Typical Scenario |
| Fixed percentage |
5% on each sale |
Simple trading venues |
| Differentiated by category |
Electronics 3%, Clothing 8% |
Marketplaces with different margins |
| Tiered by turnover |
Up to 100k — 10%, from 100k — 7% |
B2B platforms with volume discounts |
| Mixed |
% + fixed amount per transaction |
High-risk or expensive goods |
We use Stripe Connect as the baseline standard. Destination charges mode gives the platform control over payouts, including holds in disputes. Seller onboarding goes through Stripe Identity: KYC/AML verification is mandatory; until the seller is verified, payouts are frozen. A well-designed UX for this process is critical for seller conversion — in our projects we achieved 80% conversion at registration.
Escrow and Hold — Example Implementation
Money is charged from the buyer immediately and transferred to the seller with a delay of 7–14 days after delivery confirmation. This protects against fraud and allows holds in disputes. Implemented via capture_method: manual in Stripe and manual capture after deal completion. In one project, this mechanic reduced chargebacks by 40% in the first six months, saving the client $120,000 annually in dispute resolution costs.
What commission model suits your marketplace?
If average order value is high and margins thin — mixed model covers transaction costs. For B2B with volume discounts — tiered works best. Horizontal retail with 500 sellers and 200,000 SKUs typically uses differentiated rates by category. The wrong model can cost 3–5% of GMV, which directly hits your bottom line.
Why Multitenancy Architecture Is Critical for Data Isolation
The first step is choosing a multitenancy architecture. In shared-schema mode, all sellers are in the same tables with vendor_id. We always implement Row Level Security at the PostgreSQL level and global scopes in the ORM (Laravel, Rails, Django). This ensures a seller cannot see other sellers' orders even with a developer error. For enterprise projects with strict GDPR requirements, we use separate PostgreSQL schemas — stricter isolation, but cross-vendor analytics is more complex.
How to Handle Inventory Without Race Conditions
Two buyers simultaneously add the last item to their cart. Who gets it? Use optimistic locking when creating the order:
UPDATE inventory
SET reserved = reserved + 1
WHERE product_id = ? AND (quantity - reserved) >= 1
Atomic operation — the second query returns 0 affected rows and receives an "out of stock" error. Typical schema for high-traffic marketplaces. Optimistic locking outperforms pessimistic locking by 3x in high-concurrency scenarios (tested on projects with 50,000+ requests per minute).
Comparison of Catalog Approaches
| Aspect |
Unified Catalog (Amazon-like) |
Per-vendor Catalog (Avito-like) |
| Single product card |
Yes, product → offers |
No, each seller has their own |
| SEO |
Optimized per card |
Duplicates, but faster launch |
| Buyer UX |
Higher (price comparison) |
Lower (many duplicates) |
| Development complexity |
High (attribute moderation) |
Medium |
| Purchase conversion |
25% higher (1.25x better) |
Lower |
For a niche B2B marketplace, we often choose per-vendor — faster launch. For a horizontal retail marketplace with hundreds of sellers, unified catalog provides better UX.
Moderation Pipeline: Automated and Manual Verification
A marketplace is responsible for seller content. Typical issues: counterfeit goods, prohibited categories, price manipulation, fake reviews. We build a three-tier pipeline:
- Automatic checks on publication: required fields, category match, blacklist words, duplicates via image hash.
- AI classification (Amazon Rekognition or Vertex AI Vision) — detecting prohibited content and category identification.
- Manual review queue for flagged items.
State machine: draft → pending_review → active / rejected → suspended. Each transition is an event with reason and moderator. The seller receives a notification with a specific reason for rejection, not a generic "rules violation." Review verification is mandatory — only after confirmed purchase. Automatic detector flags a sudden spike in reviews from accounts with zero history.
Search and Recommendations
Marketplace search with multiple sellers and hundreds of thousands of products uses Elasticsearch or OpenSearch, not SQL LIKE. Vector search for semantics, faceted filtering via aggregations. Personalized feed based on collaborative filtering. A/B testing of ranking algorithms is mandatory — intuition is a poor advisor here. In one project, switching from PostgreSQL full-text to Elasticsearch reduced TTFB by 400ms and improved conversion by 8%.
Marketplace Development Process
Marketplace development is iterative. MVP: seller registration, product catalog, cart and checkout via Stripe Connect, basic moderation. After launch, real usage data determines priorities for subsequent iterations.
Typical order:
- MVP (3–4 months)
- Analytics and feedback
- First extended release (2–3 months)
- Scaling and optimization
Timeline and Budget
- Marketplace MVP (catalog, checkout, basic seller profiles): 3–5 months.
- Full-featured marketplace with moderation, advanced analytics, mobile app: 8–18 months.
- Adding marketplace functionality to an existing e-commerce: 2–5 months.
Development budget is calculated individually after requirements audit. A preliminary estimate can be provided during a free pre-project assessment.
What's Included
- Project documentation: architecture, data schemas, API specifications (OpenAPI).
- Access to repository, CI/CD, deployment documentation.
- Training for the client's team on platform operation.
- Technical support for the first month after launch.
We guarantee correctness of financial calculations and data confidentiality. Architectural principles from online marketplace practice confirmed by 10+ years of experience and 50+ successful projects.
Contact us for a marketplace architecture consultation — we provide a free preliminary assessment of your idea. Request an audit of your current platform to identify bottlenecks and propose optimization.
