Реализация дропшиппинга на сайте: архитектура, интеграция, синхронизация

Клиент оплачивает заказ на товар, которого уже нет у поставщика. Типичная ситуация: держатель маркетплейса пренебрёг синхронизацией остатков. Разница между успешной доставкой и убытком — в паре секунд задержки обновления. Для магазина с оборотом $9k–13k это $2.7k–3.9k убытка. А если магазин обрабатывает 500 заказов в день, ручная синхронизация отнимает до 40 часов в месяц. Мы строим дропшиппинг-систему на Laravel, которая автоматически передаёт заказы поставщикам, синхронизирует остатки и управляет маржой без хранения собственного склада. Это слой абстракции из трёх взаимосвязанных подсистем: импорт и синхронизация каталога, передача заказов поставщику и отслеживание статусов доставки. Если пренебречь любой из них, магазин принимает заказы на отсутствующие товары. Потери могут достигать 30% выручки. Наш опыт показывает: hydration mismatch между данными поставщика и магазина — главная причина убытков в дропшиппинге. Экономия на ручной обработке 1000 заказов может составлять до 80% времени, что около $90–130 в месяц. Стоимость разработки дропшиппинг-модуля рассчитывается индивидуально, но интеграция первого поставщика занимает 16–20 рабочих дней.

Какие проблемы решаем

Несинхронизированные остатки. Без обновления в реальном времени или с интервалом не более 10 минут вы продаёте то, чего уже нет. Типичная задержка обновления остатков у поставщика составляет от 5 минут до 24 часов. Мы внедряем очередь Laravel с повторными попытками — синхронизация каждые 5 минут для горячих товаров, раз в час для остальных. Это в 10 раз надёжнее пассивного ожидания ответа от поставщика. Как отмечено в документации Laravel, очереди обеспечивают асинхронную обработку задач, что критично для дропшиппинга.

Разнородные поставщики. Один работает через REST, другой — FTP с CSV, третий — SOAP. Каждый требует своего коннектора. Мы реализуем общий интерфейс SupplierConnectorInterface, под который пишется отдельная реализация. Добавление нового поставщика не ломает существующую логику.

Смешанные заказы. Когда в корзине лежат и товары со склада, и дропшиппинг-позиции, обработка должна разделяться. Мы группируем позиции по поставщикам, списываем собственные товары сразу, а дропшиппинг-заказы отправляем только после подтверждения оплаты. Покупатель видит единый заказ с несколькими трекингами.

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

Поставщики редко дают доступ к остаткам в реальном времени. Многие обновляют CSV раз в сутки. Мы решаем это через гибридный подход: для API-поставщиков — checkAvailability в реальном времени при добавлении в корзину; для CSV — прогрев очереди с разумной задержкой и кэширование на 5-10 минут. Это компромисс между актуальностью данных и нагрузкой.

Как обрабатываются смешанные заказы?

Отметим: когда в корзине соседствуют товары со склада и дропшиппинг-позиции, обработка разделяется. Собственные товары списываются немедленно после оплаты, дропшиппинг-заказы отправляются поставщику только после подтверждения оплаты. Покупатель видит единый заказ с несколькими трекингами. На уровне БД каждая позиция хранит supplier_order_id, что позволяет связать заказ магазина и заказ поставщика.

class DropshippingKernel {
    public function __construct(
        private SupplierRepositoryInterface $suppliers,
        private PriceCalculator $priceCalculator,
        private OrderDispatcher $orderDispatcher,
    ) {}

    public function calculateRetailPrice(DropshipProduct $dp): float {
        $supplier = $dp->supplier;
        $margin = $dp->margin_override ?? $supplier->default_margin;
        return $this->priceCalculator->calculate(
            supplierPrice: $dp->supplier_price,
            marginPercent: $margin,
        );
    }

    public function dispatchOrder(Order $order): void {
        $bySupplier = $order->items->groupBy(
            fn($item) => $item->product->dropshipProduct?->supplier_id
        );
        foreach ($bySupplier as $supplierId => $items) {
            if (!$supplierId) continue;
            $this->orderDispatcher->dispatch(
                supplier: Supplier::find($supplierId),
                order: $order,
                items: $items,
            );
        }
    }
}

class RestApiSupplierConnector implements SupplierConnectorInterface {
    public function placeOrder(SupplierOrderDTO $dto): SupplierOrderResult {
        $response = $this->http->post($this->supplier->api_endpoint . '/orders', [
            'headers' => ['Authorization' => 'Bearer ' . $this->getToken()],
            'json' => [
                'external_id' => $dto->orderId,
                'items' => $dto->items->map(fn($i) => [
                    'sku' => $i->supplierSku,
                    'quantity' => $i->quantity,
                ])->toArray(),
                'delivery' => [
                    'name' => $dto->recipientName,
                    'address' => $dto->deliveryAddress,
                    'phone' => $dto->phone,
                ],
            ],
        ]);
        $data = json_decode($response->getBody(), true);
        return new SupplierOrderResult(
            supplierOrderId: $data['order_id'],
            status: $data['status'],
        );
    }
}

Типовые ошибки при внедрении дропшиппинга

• Игнорирование временных зон. Поставщик и магазин могут находиться в разных часовых поясах. Синхронизация по cron без учёта этого приведёт к расхождениям.
• Отсутствие повторных попыток. Если API поставщика временно недоступен, заказ теряется. Очередь Laravel с retry-логикой решает эту проблему.
• Недостаточная валидация ответов. Всегда проверяйте статус HTTP и структуру JSON. Ошибка в одном поле может сломать весь заказ.

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

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

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

• Проектирование и документация схемы БД и архитектуры
• Реализация ядра DropshippingKernel с поддержкой нескольких поставщиков
• Коннекторы для REST, CSV, SOAP (на выбор)
• Планировщик синхронизации каталога и цен
• Обработка смешанных заказов и статусная машина
• Панель управления поставщиками в админке
• Тестирование на реальных поставщиках, отладка
• Инструкция по подключению нового поставщика

Сроки ориентировочно

Итого: 16–20 рабочих дней для полнофункциональной системы с одним поставщиком. Каждый дополнительный поставщик — 3–5 рабочих дней. Стоимость рассчитывается индивидуально после анализа требований. Получите консультацию по автоматизации дропшиппинга — мы покажем live-демо на вашем поставщике. Экономия времени на ручной обработке заказов может составить до 80%.

Гарантируем прозрачность

Мы открыто показываем архитектуру, используем промышленные паттерны (Repository, Strategy для коннекторов), предоставляем доступ к исходному коду и документации. Наш опыт — более 5 лет в разработке интернет-магазинов на Laravel, десятки интеграций с поставщиками. Запишитесь на консультацию — мы покажем, как работает система на реальном поставщике. Модель дропшиппинга требует надёжной автоматизации, и мы это делаем. Свяжитесь с нами для расчёта стоимости.