Интеграция расчёта стоимости доставки через API
Покупатель в интернет-магазине добавляет товар в корзину, переходит к оформлению — и тут стоимость доставки оказывается неожиданно высокой. Он бросает корзину. Знакомая ситуация? Мы решаем её с помощью автоматического расчёта стоимости доставки через API, показывая реальные тарифы на этапе выбора. Наш опыт — более 7 лет разработки и 15+ успешных интеграций для интернет-магазинов разного масштаба.
Представьте: покупатель уже выбрал товар, заполнил данные, но на этапе выбора доставки видит сообщение "рассчитайте доставку отдельно". Это заставляет его уйти. Наше решение показывает точную стоимость и сроки доставки от нескольких провайдеров прямо в корзине, в реальном времени. Мы интегрируем API CDEK, Boxberry, Почты России и других служб, унифицируем их ответы и кешируем результаты для быстрой загрузки. Благодаря параллельным асинхронным запросам пользователь ждёт не более 2–3 секунд. Это снижает отказы корзины на 20–30%.
Проблемы, которые мы решаем
Реализация расчёта доставки через API — не просто «дёрнуть ручку» провайдера. Вот типичные сложности:
- N+1 запросов — если опрашивать каждого провайдера последовательно, время ожидания для пользователя может превысить 10 секунд. Мы используем параллельные асинхронные запросы, сокращая задержку до времени ответа самого медленного провайдера.
- Таймауты и ошибки — API могут быть недоступны. У нас таймаут на каждый запрос — 2 секунды. Если провайдер молчит, его вариант просто не показывается.
- Неунифицированные форматы — у каждого сервиса своя структура ответа. Мы приводим их к единому объекту
DeliveryOption, с которым удобно работать и на бэкенде, и на фронтенде. - Кеширование — повторный запрос с теми же параметрами не должен долбить внешние API. Мы кешируем результат на 15 минут, ускоряя повторное открытие страницы оформления.
Как работает параллельный опрос API?
В основе — компонент DeliveryCalculator, который получает список провайдеров и параллельно запускает расчёты. Для асинхронной работы используем Guzzle Pool или ReactPHP. Вот пример реализации:
class DeliveryCalculator { private array $providers; public function calculate(Cart $cart, Address $destination): Collection { $requests = collect($this->providers)->map(function ($provider) use ($cart, $destination) { return $provider->calculateAsync($cart, $destination); // возвращает Promise }); return collect(async_all($requests)) // параллельное выполнение ->flatten() ->sortBy('price') ->filter(fn($option) => $option->isAvailable()); } } Каждый провайдер возвращает объект DeliveryOption с унифицированной структурой:
class DeliveryOption { public string $providerId; // 'cdek', 'boxberry', 'pochta' public string $serviceCode; // 'cdek_express', 'cdek_pvz' public string $name; // 'СДЭК: Экспресс' public string $type; // 'courier' | 'pvz' | 'postamat' public int $price; // в копейках public ?int $priceWithDiscount; public int $minDays; public int $maxDays; public ?string $pvzCode; // если нужно выбрать точку public array $meta; // доп. данные провайдера } Почему важно кешировать результаты расчёта?
Кеширование снижает нагрузку на API провайдеров и ускоряет повторные запросы. Мы используем ключ {cart_hash}:{destination_hash} с временем жизни 10–15 минут. При изменении состава корзины или адреса кеш сбрасывается:
$cacheKey = "delivery:{$cart->hash()}:{$destination->hash()}"; return Cache::remember($cacheKey, 900, fn() => $this->fetchFromProviders($cart, $destination)); Что входит в работу
| Этап | Содержание | Срок (раб. дни) |
|---|---|---|
| Аудит | Анализ текущей корзины и доступных провайдеров | 0,5 |
| Подключение API | Интеграция 2–3 провайдеров (CDEK, Boxberry, Почта России) | 2–3 |
| Параллельные запросы | Реализация асинхронного опроса, таймауты, обработка ошибок | 1–2 |
| Кеширование | Настройка кеша и сброса по событиям корзины | 0,5 |
| UI | Отображение вариантов с выбором ПВЗ на карте, сроки доставки | 1–2 |
| Тестирование | Проверка реальными заказами, производительность | 1 |
Итого: от 3 рабочих дней для базового подключения.
Сравнение подходов к расчёту
| Критерий | Ручной ввод | API-расчёт (наше решение) |
|---|---|---|
| Актуальность тарифов | Низкая (устаревают) | Высокая (реальное время) |
| Количество провайдеров | Не более 1–2 | 5 и более |
| Учёт габаритов | Нет | Автоматический (из карточки товара) |
| Ошибки | Высокая вероятность | Минимизированы (таймауты, кеширование) |
| Конверсия | Низкая | На 20–30% выше |
Типичные ошибки при интеграции
- Не обрабатывать габариты товаров. Если размеры не заполнены, мы подставляем дефолтные — иначе провайдер может отказать или завысить стоимость.
- Игнорировать производственный календарь. Срок доставки "1–2 дня" без учёта праздников вводит покупателя в заблуждение. Мы привязываемся к рабочим дням.
- Не тестировать с реальными корзинами. Часто ошибка проявляется только при большом количестве товаров или нестандартных адресах.
Согласно документации CDEK, таймаут запроса не должен превышать 5 секунд.
Что вы получаете после интеграции
- Работающий расчёт стоимости для 2–3 провайдеров
- Параллельные запросы с таймаутами
- Кеширование с автоматическим сбросом
- Отображение вариантов на сайте с выбором ПВЗ и сроками
- Документацию по коду и доступам
- Гарантию на интеграцию в течение 30 дней после сдачи
Свяжитесь с нами, чтобы оценить ваш проект. Мы предоставим детальную оценку сроков и стоимости, а также проконсультируем по выбору провайдеров. Закажите консультацию по интеграции расчёта доставки — мы поможем подобрать оптимальное решение.