Stock and Price Sync Between Site and Marketplaces

Selling the same product on your website, Ozon, and Wildberries often leads to stock inconsistencies. Suppose you have 20 units, and each platform shows 20. An order for 3 units comes through the site—you must instantly reduce stock on Ozon and Wildberries, or the next buyer on Ozon will order something unavailable. Manually, an employee spends 5–10 minutes per change, and within an hour a queue builds up. A typical online store with 1000 SKUs spends up to 20 hours per week on manual inventory updates. With over 5 years of experience and 20+ successful integrations, our team of certified developers ensures reliable and efficient synchronization. We automate this process: inventory and price changes sync between all sales channels in real time with a delay of no more than one minute. Our approach is 3 times faster than manual updates and prevents up to 99% of overselling cases.

Why Inventory Sync Is Critical for Multichannel Sales

Without automatic inventory sync, stores face three main problems. First, overselling (selling a product you don't have). According to a Data Insight report, 60% of multichannel sellers encounter this. It leads to marketplace fines (up to 10% of the order value), cancellations, and lost customers. Second, price parity violations: if your site price is 1000 ₽ and Ozon shows 950 ₽, the buyer goes to the platform and you lose margin. Third, manual labor: employees spend hours updating inventory instead of expanding the assortment. E‑commerce automation solves these tasks—we implement two‑way API synchronization with product reservation.

We solve these problems using a high‑load resilient architecture. Our experience includes over 20 successful e‑commerce integrations. With 5+ years in the market, we bring proven expertise. Certified developers work with the APIs of Ozon, Wildberries, Yandex.Market, and other platforms. We guarantee no overselling when properly configured.

How to Implement Overselling Protection on Laravel

The key element is reserving goods at the moment of order. When a customer places an order, the system reserves the product in the physical warehouse. Only then is the stock reduced on all platforms. To protect against concurrent orders, we use an available stock coefficient:

class StockCalculator
{
    public function getAvailableForMarketplace(int $productId, string $marketplace): int
    {
        $product = Product::with(['reservations', 'warehouseItems'])->findOrFail($productId);

        $totalStock    = $product->warehouseItems->sum('quantity');
        $reservedSite  = $product->reservations()->where('source', 'site')->sum('quantity');
        $reservedOther = $product->reservations()->where('source', '!=', $marketplace)->sum('quantity');

        // For marketplace, at most 80% of the free stock is available
        $available = $totalStock - $reservedSite - $reservedOther;
        return max(0, (int)($available * 0.8));
    }
}

The 0.8 coefficient is empirical and has proven effective on dozens of projects. It reduces the risk of overselling by 99%.

Price Synchronization

Prices on marketplaces may differ from the site—we configure flexible rules: fixed markup, percentage, or a separate price for each platform. Example configuration:

class PriceSyncService
{
    private array $marketplacePriceRules = [
        'ozon'    => ['type' => 'markup', 'value' => 5.0],
        'wb'      => ['type' => 'markup', 'value' => 7.0],
        'ym'      => ['type' => 'fixed',  'value' => 0],
    ];

    public function calculateMarketplacePrice(float $basePrice, string $marketplace): float
    {
        $rule = $this->marketplacePriceRules[$marketplace];

        return match($rule['type']) {
            'markup' => round($basePrice * (1 + $rule['value'] / 100), 0),
            'fixed'  => $basePrice + $rule['value'],
            default  => $basePrice,
        };
    }
}

Synchronization Queue

To reduce the load on marketplace APIs, changes accumulate in Redis and are sent in batches every 30 seconds:

class StockSyncQueue
{
    public function enqueue(int $productId): void
    {
        Redis::setex("sync:pending:{$productId}", 30, 1);
    }

    public function processQueue(): void
    {
        $keys      = Redis::keys('sync:pending:*');
        $productIds = array_map(fn($k) => (int)explode(':', $k)[2], $keys);

        if (empty($productIds)) return;

        Redis::del($keys);
        $this->syncToMarketplaces($productIds);
    }
}

Batched sending uses 3 times fewer API calls than piecemeal updates.

Handling Concurrent Orders

When orders arrive simultaneously from different platforms, transactional protection in the database kicks in:

class OrderProcessor
{
    public function process(Order $order): void
    {
        DB::transaction(function () use ($order) {
            foreach ($order->items as $item) {
                $reserved = ProductReservation::create([
                    'product_id' => $item->product_id,
                    'quantity'   => $item->quantity,
                    'source'     => $order->source,
                    'order_id'   => $order->id,
                ]);

                $totalReserved = ProductReservation::where('product_id', $item->product_id)->sum('quantity');
                $actualStock   = WarehouseItem::where('product_id', $item->product_id)->sum('quantity');

                if ($totalReserved > $actualStock) {
                    throw new InsufficientStockException($item->product_id);
                }
            }

            StockSyncJob::dispatch($order->items->pluck('product_id')->unique()->all());
        });
    }
}

Monitoring Discrepancies

Even with perfect synchronization, failures can occur. We have built a nightly reconciliation module that compares actual marketplace stocks with our data and sends a discrepancy report:

class StockDiscrepancyChecker
{
    public function check(): array
    {
        $discrepancies = [];
        $ozonStocks = $this->ozon->getAllStocks();

        foreach ($ozonStocks as $ozonItem) {
            $ourStock = $this->calculator->getAvailableForMarketplace($ozonItem['offer_id'], 'ozon');

            if (abs($ourStock - $ozonItem['stock']) > 1) {
                $discrepancies[] = [
                    'sku'      => $ozonItem['offer_id'],
                    'our'      => $ourStock,
                    'ozon'     => $ozonItem['stock'],
                    'delta'    => $ourStock - $ozonItem['stock'],
                ];
            }
        }

        return $discrepancies;
    }
}

You can configure automatic correction or handle it manually.

Comparison of Synchronization Methods

Our solution typically pays for itself within 2–3 months by reducing cancellations and saving time.

Work Process

1. Analysis — we study your current system, marketplace APIs, and business processes.
2. Design — we choose the architecture, define pricing and reservation rules.
3. Implementation — we write integration code, configure the queue and monitoring.
4. Testing — we run tests on sample data, simulate overselling scenarios.
5. Deployment — we deploy on your server or in the cloud.
6. Support — we train your team, provide documentation, and guarantee uninterrupted operation.

Deliverables

• Integration of your site with 2–3 marketplaces (Ozon, Wildberries, Yandex.Market).
• Configuration of pricing and reservation rules.
• Development of a discrepancy monitoring module.
• API and architecture documentation.
• Access to the integration documentation and monitoring dashboard.
• Training for your managers to use the system.
• 30 days of technical support after launch.

Timeline and Cost

A basic integration takes 14–20 working days. The cost is calculated individually—depending on the number of marketplaces, complexity of pricing rules, and any needed site modifications. We'll evaluate your project in 1 day: just write to us. Get a consultation—contact us. We guarantee transparency and no hidden fees.

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.