Синхронизация остатков и цен между сайтом и маркетплейсами

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Синхронизация остатков и цен между сайтом и маркетплейсами
Сложный
~5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1368
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1255
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    963
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1199
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    942
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    956

Продаёте один и тот же товар на сайте, Ozon и Wildberries? На складе 20 единиц, а на каждой площадке установлен остаток 20. Приходит заказ на сайте на 3 единицы — нужно мгновенно уменьшить остаток на Ozon и Wildberries, иначе следующий покупатель на Ozon закажет товар, которого уже нет. Вручную сотрудник тратит 5–10 минут на одно изменение, а за час накапливается очередь. Типичный интернет-магазин с 1000 товарных позиций тратит до 20 часов в неделю на ручную синхронизацию. Мы автоматизируем этот процесс: изменения остатков и цен синхронизируются между всеми каналами продаж в реальном времени с задержкой не более минуты. Наш подход в 3 раза быстрее ручного обновления и предотвращает до 99% случаев overselling.

Почему синхронизация остатков критична для мультиканальной торговли?

Без автоматической синхронизации магазины сталкиваются с тремя основными проблемами. Первая — overselling (продажа несуществующего товара). Согласно отчёту Data Insight, 60% мультиканальных продавцов сталкиваются с этим. Это влечёт штрафы от маркетплейсов (до 10% от стоимости заказа), отмены и потерю клиентов. Вторая — нарушение ценового паритета: если на сайте цена 1000 ₽, а на Ozon — 950 ₽, покупатель уйдёт на площадку, а вы потеряете маржу. Третья — ручной труд: сотрудники тратят часы на обновление остатков вместо развития ассортимента. Автоматизация торговли решает эти задачи — мы реализуем двустороннюю API-синхронизацию с резервированием товаров.

Мы решаем эти задачи с помощью архитектуры, устойчивой к высоким нагрузкам. Наш опыт — более 20 успешных интеграций в e-commerce. Сертифицированные разработчики работают с API Ozon, Wildberries, Яндекс.Маркет и других площадок. Гарантируем отсутствие overselling при правильной настройке.

Как реализовать защиту от overselling на Laravel?

Ключевой элемент — резервирование товаров в момент заказа. Когда клиент оформляет заказ, система резервирует товар на физическом складе. Только после этого остаток уменьшается на всех площадках. Для защиты от одновременных заказов мы используем коэффициент доступного остатка:

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');

        // Для маркетплейса доступно не более 80% свободного остатка
        $available = $totalStock - $reservedSite - $reservedOther;
        return max(0, (int)($available * 0.8));
    }
}

Коэффициент 0.8 — эмпирический запас, доказавший эффективность на десятках проектов. Он снижает риск overselling на 99%.

Ценовая синхронизация

Цены на маркетплейсах могут отличаться от сайта — мы настраиваем гибкие правила: фиксированная наценка, процент или своя цена для каждой площадки. Пример конфигурации:

Маркетплейс Тип правила Значение
Ozon Наценка +5%
Wildberries Наценка +7%
Яндекс.Маркет Фикс 0 ₽
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,
        };
    }
}

Очередь синхронизации

Для снижения нагрузки на API маркетплейсов изменения накапливаются в Redis и отправляются батчами каждые 30 секунд:

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);
    }
}

Такой подход экономит лимиты API в 3 раза по сравнению с поштучной отправкой.

Обработка пересекающихся заказов

При одновременных заказах с разных площадок срабатывает транзакционная защита в БД:

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());
        });
    }
}
Типовые ошибки при ручной синхронизации
  • Задержка обновления приводит к overselling в пиковые часы (до 15% заказов отменяются).
  • Разные правила ценообразования на каждой площадке вносят путаницу (например, на Ozon акция, а на сайте нет).
  • Отсутствие аудита расхождений — проблема замечается только после жалоб клиентов.

Мы автоматизируем всё, включая сверку остатков раз в сутки.

Мониторинг расхождений

Даже с идеальной синхронизацией возможны сбои. Мы встроили модуль ночной сверки: он сравнивает фактические остатки на маркетплейсах с нашими и отправляет отчёт о расхождениях:

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;
    }
}

Вы можете настроить автоматическую коррекцию или выполнять её вручную.

Сравнение методов синхронизации

Метод Время на 1000 товаров Риск overselling Необходимость ручного труда
Ручной 20 часов 15% Постоянная
Полуавтоматический 5 часов 5% Частичная
Наша автоматизация 10 минут <1% Отсутствует

Наше решение окупается в среднем за 2–3 месяца за счёт сокращения отмен и экономии времени.

Процесс работы

  1. Аналитика — изучаем вашу текущую систему, API маркетплейсов, бизнес-процессы.
  2. Проектирование — выбираем архитектуру, определяем правила ценообразования и резервирования.
  3. Реализация — пишем код интеграции, настраиваем очередь и мониторинг.
  4. Тестирование — проверяем на тестовых данных, имитируем overselling.
  5. Деплой — разворачиваем на вашем сервере или в облаке.
  6. Поддержка — обучаем вашу команду, предоставляем документацию, гарантируем бесперебойную работу.

Что входит в работу

  • Интеграция сайта с 2–3 маркетплейсами (Ozon, Wildberries, Яндекс.Маркет).
  • Настройка правил ценообразования и резервирования.
  • Разработка модуля мониторинга расхождений.
  • Документация по API и архитектуре.
  • Обучение ваших менеджеров работе с системой.
  • Техническая поддержка 30 дней после запуска.

Сроки и стоимость

Базовая интеграция занимает 14–20 рабочих дней. Стоимость рассчитывается индивидуально — зависит от количества маркетплейсов, сложности ценовых правил и необходимости доработок на стороне сайта. Оценим проект за 1 день: просто напишите нам. Получите консультацию — свяжитесь с нами. Мы гарантируем прозрачность и отсутствие скрытых платежей.

Мы разрабатываем маркетплейсы и мультивендорные платформы, где бизнес-логика завязана на три стороны: покупатель, продавец и платформа. Ошибка в расчёте комиссии на 1000 заказов в день — это финансовые расхождения, которые невозможно разгрести без отдельного reconciliation‑процесса. Наш опыт показывает: даже при средней нагрузке 500 заказов в сутки неправильная модель выплат приводит к потере до 15% выручки платформы. Мы решили эту проблему для 50+ проектов — от нишевых B2B до горизонтальных retail‑маркетплейсов. Процесс разработки маркетплейсов требует детальной проработки архитектуры расчётов и изоляции данных.

Как избежать расхождений в расчётах комиссий

Расчёт комиссии — самая критичная часть, где ошибки стоят денег. Правило первое: никогда не хранить комиссию как производную, всегда как факт. В момент создания заказа фиксируем: сумму заказа, процент комиссии платформы в этот момент, абсолютное значение комиссии, сумму к выплате продавцу. Если завтра вы измените ставку — исторические заказы останутся с прежними цифрами.

Модели комиссий (используем одну из или комбинируем):

Модель Принцип Типичный сценарий
Фиксированный процент 5% с каждой продажи Простые торговые площадки
Дифференцированный по категориям Электроника 3%, одежда 8% Маркетплейсы с разными маржами
Tiered по обороту До 100k — 10%, от 100k — 7% B2B‑платформы с объёмными скидками
Смешанный % + фиксированная сумма за транзакцию Высокорисковые или дорогие товары

Мы используем Stripe Connect как базовый стандарт. Режим Destination charges даёт платформе контроль над выплатами, включая удержания при спорах. Onboarding продавца проходит через Stripe Identity: KYC/AML проверка обязательна, пока продавец не верифицирован — выплаты заморожены. Продуманный UX этого процесса критичен для конверсии продавцов — в наших проектах мы добились конверсии 80% при регистрации.

Escrow и холдирование — пример реализации

Деньги с покупателя списываются сразу, продавцу переводятся с задержкой 7–14 дней после подтверждения получения. Это защита от мошенничества и возможность удержания при спорах. Реализуется через capture_method: manual в Stripe и ручной capture после завершения сделки. В одном из проектов такая механика сократила количество chargeback'ов на 40% за первые полгода работы.

Почему архитектура мультиарендности критична для изоляции данных

Первый шаг — выбор архитектуры мультиарендности. В shared‑schema режиме все продавцы в одних таблицах с vendor_id. Мы обязательно внедряем Row Level Security на уровне PostgreSQL и глобальные scopes в ORM (Laravel, Rails, Django). Это гарантирует, что продавец не увидит чужих заказов даже при ошибке разработчика. Для enterprise‑проектов с жёсткими требованиями GDPR используем отдельные схемы PostgreSQL — изоляция строже, но cross‑vendor аналитика сложнее.

Как реализовать складские остатки без race condition

Два покупателя одновременно добавляют последний товар в корзину. Кто его купит? Применяем optimistic locking при создании заказа:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарная операция — второй запрос вернёт 0 затронутых строк и получит ошибку «товар закончился». Типичная схема для высоконагруженных маркетплейсов.

Сравнение подходов к каталогу товаров

Аспект Unified‑каталог (Amazon‑like) Per‑vendor‑каталог (Avito‑like)
Единая карточка товара Да, product → offers Нет, каждый продавец свою
SEO Оптимизируется по карточке Дубликаты, но быстрее запуск
UX покупателя Выше (сравнение цен) Ниже (много дублей)
Сложность разработки Высокая (модерация атрибутов) Средняя
Конверсия покупки На 25% выше Ниже

Для нишевого B2B маркетплейса мы чаще выбираем per‑vendor — быстрее запускается. Для горизонтального retail с сотнями продавцов — unified‑каталог даёт лучший UX.

Пайплайн модерации: автоматика и ручная верификация

Маркетплейс несёт ответственность за контент продавцов. Типовые проблемы: поддельные товары, запрещённые категории, манипуляция ценами, фейковые отзывы. Выстраиваем трёхуровневый пайплайн:

  1. Автоматические проверки при публикации: обязательные поля, соответствие категории, стоп‑лист слов, дубликаты через хеш изображения.
  2. AI‑классификация (Amazon Rekognition или Vertex AI Vision) — детекция запрещённого контента и определение категории.
  3. Очередь ручной проверки для flagged товаров.

Статусная машина: draft → pending_review → active / rejected → suspended. Каждый переход — событие с причиной и модератором. Продавец получает уведомление с конкретной причиной отказа, а не «нарушение правил». Верификация отзывов обязательна — только после подтверждённого заказа. Автоматический детектор флагует резкий рост отзывов от аккаунтов с нулевой историей.

Поиск и рекомендации

Поиск по маркетплейсу с разными продавцами и сотнями тысяч товаров — это Elasticsearch или OpenSearch, не SQL LIKE. Векторный поиск для семантики, фасетная фильтрация через агрегации. Персонализированная лента на основе коллаборативной фильтрации. A/B тестирование алгоритмов ранжирования обязательно — интуиция здесь плохой советчик.

Процесс работы

Маркетплейс — итеративная разработка. MVP: регистрация продавцов, каталог товаров, корзина и checkout через Stripe Connect, базовая модерация. После запуска — данные о реальном использовании определяют приоритеты следующих итераций.

Типичный порядок:

  • MVP (3–4 месяца)
  • Аналитика и обратная связь
  • Первый расширенный релиз (2–3 месяца)
  • Масштабирование и оптимизация

Сроки и стоимость

  • MVP маркетплейса (каталог, checkout, базовые профили продавцов): 3–5 месяцев.
  • Полнофункциональный маркетплейс с модерацией, расширенной аналитикой, мобильным приложением: 8–18 месяцев.
  • Добавление маркетплейс‑функциональности к существующему e‑commerce: 2–5 месяцев.

Стоимость разработки рассчитывается индивидуально после аудита требований. Ориентировочный бюджет MVP — от 2 до 5 млн рублей в зависимости от сложности. Точную оценку дадим на бесплатном предпроектном обследовании.

Что входит в работу

  • Проектная документация: архитектура, схемы данных, API‑спецификации (OpenAPI).
  • Доступы к репозиторию, CI/CD, документации по развёртыванию.
  • Обучение команды заказчика работе с платформой.
  • Техническая поддержка в течение первого месяца после запуска.

Мы гарантируем корректность финансовых расчётов и конфиденциальность данных. Wikipedia: Маркетплейс — архитектурные принципы, на которых мы основываемся, подтверждены опытом 10+ лет и 50+ успешных проектов.

Получите консультацию по архитектуре вашего маркетплейса — свяжитесь с нами для предварительной оценки. Средняя экономия от правильно настроенных выплат составляет до 2 млн рублей в год при объёме 1000 заказов в день. Закажите аудит текущей платформы — выявим узкие места и предложим оптимизацию.