Unified Order Management Dashboard for All Marketplaces

Managers spend up to 2 hours a day switching between Ozon, Wildberries, and Yandex.Market dashboards. According to our data, manual synchronization leads to 15–20% order loss and up to 80% of negative reviews due to delays. Automation reduces these risks to zero, and the average order processing time drops from 5 minutes to 30 seconds, saving operators up to 50,000 rubles per month. A unified order dashboard solves this: it collects all orders from the site and marketplaces into one interface. The manager works in a single window — sees new orders, changes statuses, prints labels without switching between platforms. Payback for such a solution is on average 2–3 months due to reduced sales department labor costs. We have 12+ years of experience in web development and over 50 successful marketplace integrations.

Why a Unified Order Management Dashboard?

Manual order export — operators copy data from five dashboards, make errors in numbers, lose orders. FBS orders with short assembly deadlines (4 hours on Ozon) go unnoticed. Duplicates and conflicts — the same order may be created twice if the marketplace API returns data again. Our solution uses the Repository pattern for deduplication and Adapter to unify data from different sources. This ensures processing of up to 1000 orders per minute without loss. Compare: manual handling requires 2–3 operators, the automated dashboard handles it alone — 10 times faster. A single order window combining Ozon, Wildberries, Yandex.Market, and the site gives full control over all processes.

How We Sync Orders Without Loss?

Synchronization is based on the Laravel Queue job system. Each marketplace is polled at a set frequency (typically every 5–15 minutes). All new and changed orders are mapped to a common format and saved locally. For reliability, we log every run and automatically retry on failures. The concept of queues is described in Laravel Queues.

Here’s what the core synchronization class looks like:

// Periodically pull orders from all marketplaces
class MarketplaceOrdersSyncJob implements ShouldQueue
{
    public function handle(): void
    {
        $adapters = [
            'ozon' => app(OzonAdapter::class),
            'wb'   => app(WildberriesAdapter::class),
            'ym'   => app(YandexMarketAdapter::class),
        ];

        foreach ($adapters as $source => $adapter) {
            try {
                $lastSync = SyncLog::where('source', $source)->max('synced_at')
                    ?? now()->subHours(24);

                $orders = $adapter->getOrdersSince($lastSync);

                foreach ($orders as $rawOrder) {
                    $unified = $adapter->toUnifiedOrder($rawOrder);
                    Order::updateOrCreate(
                        ['source' => $source, 'source_order_id' => $unified->sourceOrderId],
                        $unified->toArray()
                    );
                }

                SyncLog::create(['source' => $source, 'synced_at' => now(), 'count' => count($orders)]);
            } catch (Exception $e) {
                Log::error("Sync failed for {$source}", ['error' => $e->getMessage()]);
            }
        }
    }
}

Order Deduplication Eliminates Duplicates — Unified Dashboard

Without deduplication, a repeated API request (due to network failure) creates a duplicate order. We use a unique source_order_id for each order within a marketplace, so updateOrCreate simply updates the existing record. This prevents duplicates even on repeated calls. The Laravel React panel built on this principle reliably handles thousands of orders daily.

Dashboard Functionality

Order List

• Filtering by source (site, Ozon, WB, Yandex.Market)
• Filtering by status, date, amount
• Search by order number, customer name, SKU
• Urgency indicator (FBS orders with short assembly time — red background)
• Bulk actions: confirm multiple orders, print labels

function OrdersDashboard() {
  const [filters, setFilters] = useState({ source: 'all', status: 'all', search: '' });

  const { data, isLoading } = useQuery({
    queryKey: ['orders', filters],
    queryFn:  () => fetchOrders(filters),
    refetchInterval: 60_000,  // refresh every minute
  });

  return (
    <div>
      <OrderFilters filters={filters} onChange={setFilters} />

      {/* Counters by source */}
      <div className="grid grid-cols-5 gap-3 mb-6">
        {['site', 'ozon', 'wb', 'ym'].map(source => (
          <SourceCounter key={source} source={source} count={data?.counts[source] ?? 0} />
        ))}
      </div>

      <OrdersTable
        orders={data?.orders ?? []}
        loading={isLoading}
        onStatusChange={handleStatusChange}
      />
    </div>
  );
}

function SourceCounter({ source, count }: { source: string; count: number }) {
  const labels = { site: 'Site', ozon: 'Ozon', wb: 'WB', ym: 'Yandex.Market' };
  return (
    <div className={cn('rounded-xl p-4 border', sourceColors[source])}>
      <p className="text-2xl font-bold">{count}</p>
      <p className="text-sm text-gray-600">{labels[source]}</p>
    </div>
  );
}

Order Card

• Full customer and delivery data
• Product list with photos
• Action buttons depending on status (confirm, cancel, send to assembly)
• Print label / transfer act
• Status change history with timestamps

Label Printing

Each marketplace requires its own label format. We automatically select a template based on the source:

public function printLabel(Order $order): Response
{
    if ($order->source === 'ozon') {
        $label = $this->ozon->getPostingLabel($order->source_order_id);
        return response($label, 200, ['Content-Type' => 'application/pdf']);
    }

    if ($order->source === 'wb') {
        $label = $this->wb->getLabel($order->source_order_id);
        return response($label, 200, ['Content-Type' => 'application/pdf']);
    }

    // For site, generate ourselves
    $pdf = PDF::loadView('labels.order', compact('order'));
    return $pdf->stream("order-{$order->number}.pdf");
}

For bulk printing, you can select multiple orders and click "Print Labels" — the system generates a single PDF with all labels.

New Order Notifications

Real-time notifications via WebSocket (Laravel Echo / Pusher) — when a new order arrives from any marketplace, the dashboard updates automatically and shows a toast notification. The operator can immediately start working on the order without refreshing the page.

Process Overview

1. Analysis — we study your marketplace APIs, document fields for synchronization.
2. Design — design database structure, queue system, notification scheme.
3. Implementation — write adapters, interface, sync logic.
4. Testing — test with sample orders, simulate network failures, data conflicts.
5. Deployment — deploy on your hosting or our server, set up monitoring.

Comparison of Order Management Approaches

Timeline and What’s Included

Dashboard for 3 marketplaces with synchronization and label printing: 20–28 working days. We work at a fixed cost, calculated individually. Includes:

• Integration of up to 4 sources (site + 3 marketplaces)
• Web interface with order list, filters, search, and counters
• Label printing for each marketplace
• Notification system (WebSocket + email)
• Administration documentation
• Operator training (1 hour)
• Synchronization warranty — 6 months

Typical Integration Mistakes

• Token expiration — most marketplaces issue tokens valid for 24 hours. We automatically refresh them via a refresh mechanism.
• Timezone differences — an order created at 23:59 Moscow time may appear as tomorrow's. We convert everything to UTC.
• Duplicates on retries — if the API fails, the request is repeated, potentially creating duplicates. We use source_order_id for deduplication.

Get a consultation for your project — we'll help estimate timeline and cost. Contact us to receive a detailed calculation.

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)

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.

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

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:

1. Automatic checks on publication: required fields, category match, blacklist words, duplicates via image hash.
2. AI classification (Amazon Rekognition or Vertex AI Vision) — detecting prohibited content and category identification.
3. 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.