Интеграция расчёта стоимости доставки через API

Интеграция расчёта стоимости доставки через 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));

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

Итого: от 3 рабочих дней для базового подключения.

Сравнение подходов к расчёту

Типичные ошибки при интеграции

• Не обрабатывать габариты товаров. Если размеры не заполнены, мы подставляем дефолтные — иначе провайдер может отказать или завысить стоимость.
• Игнорировать производственный календарь. Срок доставки "1–2 дня" без учёта праздников вводит покупателя в заблуждение. Мы привязываемся к рабочим дням.
• Не тестировать с реальными корзинами. Часто ошибка проявляется только при большом количестве товаров или нестандартных адресах.

Согласно документации CDEK, таймаут запроса не должен превышать 5 секунд.

Что вы получаете после интеграции

• Работающий расчёт стоимости для 2–3 провайдеров
• Параллельные запросы с таймаутами
• Кеширование с автоматическим сбросом
• Отображение вариантов на сайте с выбором ПВЗ и сроками
• Документацию по коду и доступам
• Гарантию на интеграцию в течение 30 дней после сдачи

Свяжитесь с нами, чтобы оценить ваш проект. Мы предоставим детальную оценку сроков и стоимости, а также проконсультируем по выбору провайдеров. Закажите консультацию по интеграции расчёта доставки — мы поможем подобрать оптимальное решение.

Как интеграция служб доставки влияет на конверсию?

Интернет-магазин теряет клиентов не на странице товара, а на шаге выбора доставки — это подтверждают наши проекты. Слишком мало вариантов, неверные тарифы, отсутствие калькулятора — и покупатель уходит. По данным Baymard Institute, 22% пользователей отказываются от заказа из-за неудобных условий доставки. Если магазин не предлагает хотя бы две-три службы с прозрачным расчётом, потеря выручки становится системной.

Мы занимаемся подключением логистических сервисов более шести лет и реализовали свыше 30 проектов для магазинов разного масштаба — от нишевых брендов до маркетплейсов с миллионными оборотами. Интеграция — это не просто «вывести список ПВЗ». Это актуальные тарифы по весу и габаритам, автоматическое создание заявок, отслеживание статуса, обработка ошибок API. Подход «под ключ» гарантирует, что система будет работать без сбоев даже при пиковых нагрузках в Черную пятницу.

Какие проблемы решает настройка доставки?

У каждой службы свой API, своя степень зрелости документации и набор неочевидных ограничений. Разберём три самых частых сложности.

СДЭК API v2 — наиболее зрелый из российских перевозчиков. OAuth 2.0 авторизация (токен живёт 24 часа, нужна логика рефреша), REST JSON. Расчёт тарифов через POST /v2/calculator/tariff, список ПВЗ через GET /v2/deliverypoints. Типичная ошибка: забыть передать from_location и packages с реальными весом и размерами — в ответ приходит error_code: 3 без объяснений. ПВЗ нужно кешировать (список меняется нечасто), иначе каждый запрос к чекауту генерирует отдельный API-вызов.

Boxberry API — проще по функционалу, XML в ряде методов (legacy), часть API — REST. Токен передаётся как GET-параметр (не Authorization header), что нетипично. Список ПВЗ возвращает всё сразу (~2MB JSON), его обязательно нужно кэшировать в Redis или БД с ночным обновлением.

Почта России API — самый сложный из российских. SOAP + REST гибрид, требует договора и настройки в ЛК. x-user-authorization + Authorization — два разных заголовка одновременно. Нормативные отправления, EMS, 1-й класс — разные тарифные группы. Индексы ПВЗ (почтовые отделения) — отдельный справочник, не всегда актуальный.

DHL Express API — для международной доставки. XML-based API (DHL XML Services), хотя есть более новый MyDHL+ API. Требует зарегистрированного account number. Rate Request для расчёта, Shipment Request для создания накладной, возвращает PDF с label.

Почему кэширование ПВЗ и тарифов обязательно?

Кэширование — не опция, а необходимость. API СДЭК имеет лимит 1000 запросов в минуту, Boxberry — 300. Без кэша даже средний магазин с 1000 посетителей в час рискует получить 429 ошибку. Мы используем Redis или PostgreSQL с TTL 30 минут для тарифов и ночное обновление для ПВЗ. Это снижает нагрузку на API на 70–80% и ускоряет отображение на странице. Параллельные запросы с кэшем сокращают время расчёта в 7 раз по сравнению с последовательными — вместо 2,8 секунд клиент получает тарифы за 380 мс.

Что входит в работу по подключению?

Каждый проект включает:

• документацию: описание архитектуры, схемы данных, инструкции по эксплуатации
• предоставление доступов: API-ключи, вебхуки, тестовые контуры
• обучение команды: вебинар или письменная инструкция по работе с админкой
• поддержку на старте: 2 недели пост-релизного мониторинга и исправлений

Как строим интеграцию

1. Абстракция над провайдерами. Ни один магазин не использует одну службу доставки вечно. Строим единый интерфейс: DeliveryProvider с методами calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Каждая служба — отдельная реализация. Переключить провайдера или добавить нового — не означает переписывать checkout.

2. Кэширование ПВЗ. Геопоиск ПВЗ по координатам или городу — частый запрос. Тянуть с API каждый раз нельзя (лимиты, задержка). Схема: ночное задание обновляет таблицу pickup_points в PostgreSQL с PostGIS или просто с lat/lng. Поиск ближайших — ORDER BY ST_Distance() или простая формула Хаверсина, если PostGIS избыточен.

3. Виджет на фронтенде. СДЭК предоставляет официальный JS-виджет (@cdek-it/widget) — быстро, но ограниченно в кастомизации. Для нестандартных дизайнов — кастомный виджет: карта (Яндекс.Карты API или Leaflet с тайлами 2GIS), список ПВЗ с фильтрами, детальная карточка точки с режимом работы.

4. Трекинг статусов. Статусы заказов приходят либо через webhook (СДЭК поддерживает), либо через периодический polling (Boxberry, Почта России). Для polling — очередь задач (Laravel Queue, Bull для Node.js), проверка раз в 4–6 часов, нотификация покупателю при смене статуса через email или SMS.

Кейс: мультиперевозчик для WooCommerce. Магазин спортивного питания: СДЭК + Boxberry + самовывоз из 3 магазинов. Плагин Доставки WooCommerce не давал нужной гибкости — написали кастомный Shipping Method. calculate_shipping() делает параллельные запросы к обоим API через GuzzleHttp\Pool, агрегирует тарифы, фильтрует по зоне доставки (нет СДЭК — показываем только Boxberry). Кэш тарифов в Redis на 30 минут по ключу delivery:{city}:{weight}:{dimensions}. Время расчёта: было 2.8s (последовательные запросы), стало 380ms (параллельно + кэш), что дало рост конверсии на 15% на этапе чекаута.

Процесс и сроки

Стоимость рассчитывается индивидуально — зависит от количества провайдеров, необходимости кастомного виджета и сложности трекинга. Интеграция одной службы доставки в среднем обходится от 45 000 до 90 000 ₽. При автоматизации обработки 500 заказов в месяц экономия на операционных расходах достигает 360 000 ₽ в год. Для точной оценки свяжитесь с нами: мы проанализируем ваш магазин и предложим решение.

Типичные ошибки при самостоятельной настройке

• Забыть про квоты API — приводит к блокировке доступа
• Не кэшировать список ПВЗ — страница загружается 5+ секунд
• Игнорировать обработку ошибок (timeout, 504) — потеря заказов
• Не тестировать граничные веса и размеры — расчёт уходит в бесконечность

Наш опыт (30+ интеграций) подтверждает: правильная архитектура с кэшем и параллелизацией сокращает время ответа до 300–400 мс даже при трёх провайдерах. Закажите интеграцию служб доставки — получите консультацию инженера без обязательств. Свяжитесь с нами, и мы подберём оптимальное решение для вашего магазина.