Клієнт оплачує замовлення на товар, якого вже немає у постачальника. Типова ситуація: власник маркетплейсу знехтував синхронізацією залишків. Різниця між успішною доставкою та збитком — у парі секунд затримки оновлення. Це може призвести до значних збитків. А якщо магазин обробляє 500 замовлень на день, ручна синхронізація забирає до 40 годин на місяць. Ми будуємо дропшипінгову систему на Laravel, яка автоматично передає замовлення постачальникам, синхронізує залишки та керує маржею без зберігання власного складу. Це шар абстракції з трьох взаємопов'язаних підсистем: імпорт і синхронізація каталогу, передача замовлень постачальнику та відстеження статусів доставки. Якщо знехтувати будь-якою з них, магазин приймає замовлення на відсутні товари. Втрати можуть сягати 30% виручки. Наш досвід показує: hydration mismatch між даними постачальника та магазину — головна причина збитків у дропшипінгу. Економія на ручній обробці 1000 замовлень може становити до 80% часу. Вартість розробки дропшипінгового модуля розраховується індивідуально, але інтеграція першого постачальника займає 16–20 робочих днів.
Які проблеми вирішуємо
Несинхронізовані залишки. Без оновлення в реальному часі або з інтервалом не більше 10 хвилин ви продаєте те, чого вже немає. Типова затримка оновлення залишків у постачальника становить від 5 хвилин до 24 годин. Ми впроваджуємо чергу Laravel із повторними спробами — синхронізація кожні 5 хвилин для гарячих товарів, раз на годину для решти. Це в 10 разів надійніше пасивного очікування відповіді від постачальника. Як зазначено в документації Laravel, черги забезпечують асинхронну обробку завдань, що критично для дропшипінгу.
Різнорідні постачальники. Один працює через REST, інший — FTP з CSV, третій — SOAP. Кожен потребує свого конектора. Ми реалізуємо спільний інтерфейс SupplierConnectorInterface, під який пишеться окрема реалізація. Додавання нового постачальника не ламає існуючу логіку.
Змішані замовлення. Коли в кошику лежать і товари зі складу, і дропшипінгові позиції, обробка має розділятися. Ми групуємо позиції за постачальниками, списуємо власні товари одразу, а дропшипінгові замовлення відправляємо лише після підтвердження оплати. Покупець бачить єдине замовлення з кількома трекінгами.
Чому синхронізація каталогу — найвужче місце?
Постачальники рідко дають доступ до залишків у реальному часі. Багато оновлюють CSV раз на добу. Ми вирішуємо це через гібридний підхід: для API-постачальників — checkAvailability у реальному часі при додаванні в кошик; для CSV — прогрів черги з розумною затримкою та кешування на 5-10 хвилин. Це компроміс між актуальністю даних і навантаженням.
| Тип інтеграції | Затримка оновлення | Складність реалізації | Рекомендація |
|---|---|---|---|
| REST API | Секунди-хвилини | Середня | Для гарячих товарів |
| CSV (FTP/HTTP) | Години-дні | Низька | Для каталогів із рідкісним оновленням |
| SOAP | Хвилини-години | Висока | Для legacy-постачальників |
Як обробляються змішані замовлення?
Зазначимо: коли в кошику сусідять товари зі складу та дропшипінгові позиції, обробка розділяється. Власні товари списуються негайно після оплати, дропшипінгові замовлення відправляються постачальнику тільки після підтвердження оплати. Покупець бачить єдине замовлення з кількома трекінгами. На рівні БД кожна позиція зберігає supplier_order_id, що дозволяє пов'язати замовлення магазину та замовлення постачальника.
Архітектура ядра DropshippingKernel
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, ); } } } Конектор для REST API:
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. Помилка в одному полі може зламати все замовлення.
Процес роботи
- Аналітика — вивчаємо формати постачальників, частоту оновлення, обмеження API. Складаємо карту полів.
- Проєктування — схема БД, ядро, інтерфейси.
- Реалізація — пишемо моделі, конектори, чергу синхронізації, диспетчер замовлень.
- Тестування — тестуємо на sandbox-постачальнику, перевіряємо граничні випадки: скасування, часткове повернення, помилки валідації.
- Деплой та навчання — налаштовуємо моніторинг, логи, дашборд в адмінці.
Що входить у роботу
- Проєктування та документація схеми БД і архітектури
- Реалізація ядра
DropshippingKernelз підтримкою кількох постачальників - Конектори для REST, CSV, SOAP (на вибір)
- Планувальник синхронізації каталогу та цін
- Обробка змішаних замовлень і статусна машина
- Панель керування постачальниками в адмінці
- Тестування на реальних постачальниках, налагодження
- Інструкція з підключення нового постачальника
Строки орієнтовно
| Етап | Строк |
|---|---|
| Проєктування схеми БД та архітектури | 2 дні |
| Базові моделі, ядро, інтерфейси | 3 дні |
| Перший конектор постачальника (REST API) | 2 дні |
| Синхронізація каталогу (cron + queue) | 2 дні |
| Dispatch замовлень та обробка статусів | 3 дні |
| UI в адмінці: управління постачальниками | 2 дні |
| Тестування та налагодження | 2 дні |
| Комплексне тестування + навчання | 2 дні |
Разом: 16–20 робочих днів для повнофункціональної системи з одним постачальником. Кожен додатковий постачальник — 3–5 робочих днів. Вартість розраховується індивідуально після аналізу вимог. Отримайте консультацію з автоматизації дропшипінгу — ми покажемо live-демо на вашому постачальнику. Економія часу на ручній обробці замовлень може становити до 80%.
Гарантуємо прозорість
Ми відкрито показуємо архітектуру, використовуємо промислові патерни (Repository, Strategy для конекторів), надаємо доступ до вихідного коду та документації. Наш досвід — понад 5 років у розробці інтернет-магазинів на Laravel, десятки інтеграцій з постачальниками. Запишіться на консультацію — ми покажемо, як працює система на реальному постачальнику. Модель дропшипінгу потребує надійної автоматизації, і ми це робимо. Зв'яжіться з нами для розрахунку вартості.