Разработка калькулятора доставки для интернет-магазина

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

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

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

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка калькулятора доставки для интернет-магазина
Средний
~3-5 дней
Часто задаваемые вопросы

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

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

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

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

Покупатель добавляет товары в корзину, переходит к оформлению и видит неожиданно высокую стоимость доставки. По данным исследований, неожиданная стоимость доставки — причина 60% брошенных корзин. Калькулятор доставки, предварительно показывающий стоимость, решает эту проблему и повышает конверсию на 15–30%. Реализация такого калькулятора — нетривиальная задача: нужно учесть объёмный вес, интегрироваться с API нескольких служб доставки (СДЭК, Boxberry, Почта России), обеспечить отказоустойчивость и скорость расчётов. Запросы к API занимают 200–800 мс и часто платные, поэтому требуется грамотное кеширование и параллельная обработка. Мы рассмотрим технические детали: от хранения тарифов в базе до параллельных запросов и обработки ошибок. Приведём примеры кода на Laravel и React, расскажем о кешировании и работе с объёмным весом. Внедрение агрегатора окупается за 2–3 месяца, экономя значительную сумму на доставке.

Наша команда имеет 5+ лет опыта в e-commerce разработке и реализовала 20+ калькуляторов доставки. Это позволило накопить типовые решения, ускоряющие внедрение. Обращайтесь — мы поможем подобрать оптимальную архитектуру под ваш бюджет.

Что считает калькулятор

Стоимость доставки зависит от параметров, которые нужно получить из разных источников:

  • Адрес склада (откуда везут) — может быть фиксированным или ближайшим магазином.
  • Адрес покупателя (куда везут) — до двери или до пункта выдачи.
  • Вес и габариты товаров в корзине (что везут).
  • Выбранный способ доставки — курьер, ПВЗ, постамат, Почта России.
  • Срочность — стандарт или экспресс.

Параметры товаров хранятся в базе данных интернет-магазина. Тарифы доставки — либо в собственных таблицах (для партнёрских договоров с фиксированными ценами), либо приходят в реальном времени через API службы доставки.

Локальные таблицы и API: два подхода к расчёту

Локальные тарифные таблицы

Для простых случаев — когда есть договор с фиксированными ценами или доставка своими силами — тарифы хранятся локально:

CREATE TABLE shipping_zones (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    regions TEXT[],
    base_price DECIMAL(10,2),
    price_per_kg DECIMAL(10,2),
    price_per_km DECIMAL(10,2),
    min_days INT,
    max_days INT
);

CREATE TABLE shipping_methods (
    id SERIAL PRIMARY KEY,
    zone_id INT REFERENCES shipping_zones(id),
    name VARCHAR(100),
    carrier VARCHAR(50),
    multiplier DECIMAL(4,2) DEFAULT 1.0,
    free_from DECIMAL(10,2)
);
class LocalShippingCalculator
{
    public function calculate(Cart $cart, Address $destination): Collection
    {
        $zone = $this->zoneDetector->detect($destination->city);
        $weight = $cart->totalWeight();
        $orderTotal = $cart->total();

        return ShippingMethod::where('zone_id', $zone->id)->get()
            ->map(function (ShippingMethod $method) use ($weight, $orderTotal, $zone) {
                $cost = $zone->base_price + ($weight * $zone->price_per_kg);
                $cost *= $method->multiplier;
                if ($method->free_from && $orderTotal >= $method->free_from) {
                    $cost = 0;
                }
                return [
                    'id'       => $method->id,
                    'name'     => $method->name,
                    'carrier'  => $method->carrier,
                    'cost'     => round($cost, 2),
                    'min_days' => $zone->min_days * $method->multiplier < 1 ? 1 : (int)($zone->min_days / $method->multiplier),
                    'max_days' => $zone->max_days,
                    'free'     => $cost === 0.0,
                ];
            });
    }
}

API-расчёт в реальном времени: пример с СДЭК

Отметим: когда нужны актуальные тарифы службы доставки, запрос уходит в их API:

class CdekShippingCalculator
{
    private string $baseUrl = 'https://api.cdek.ru/v2';

    public function calculate(
        string $fromCity,
        string $toCity,
        float $weight,
        array $dimensions
    ): array {
        $token = $this->authenticate();
        $response = Http::withToken($token)
            ->post("{$this->baseUrl}/calculator/tarifflist", [
                'from_location' => ['city' => $fromCity],
                'to_location'   => ['city' => $toCity],
                'packages'      => [[
                    'weight' => (int)($weight * 1000),
                    'length' => $dimensions['length'],
                    'width'  => $dimensions['width'],
                    'height' => $dimensions['height'],
                ]],
            ]);
        return collect($response->json('tariff_codes'))
            ->map(fn($t) => [
                'tariff_code'  => $t['tariff_code'],
                'tariff_name'  => $t['tariff_name'],
                'cost'         => $t['delivery_sum'],
                'min_days'     => $t['period_min'],
                'max_days'     => $t['period_max'],
            ])
            ->toArray();
    }
}

Сравнение подходов

Критерий Локальные таблицы API в реальном времени
Скорость расчёта <10 мс 200–800 мс
Актуальность тарифов Ручное обновление Автоматически
Сложность интеграции Низкая Средняя
Стоимость обслуживания Низкая Средняя (комиссии API)

Локальные таблицы быстрее API в 10–80 раз, но уступают в гибкости. Выбор зависит от объёмов и требований к актуальности.

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

Реальный калькулятор обычно показывает варианты от нескольких служб одновременно. Запросы уходят параллельно. Если один сервис недоступен — показываем остальные. Покупатель не видит ошибку, только меньше вариантов.

public function getShippingOptions(Cart $cart, Address $address): array
{
    $weight = $cart->totalWeight();
    $dimensions = $cart->boundingBox();

    $results = collect([
        'cdek'     => fn() => $this->cdek->calculate($address, $weight, $dimensions),
        'boxberry' => fn() => $this->boxberry->calculate($address, $weight, $dimensions),
        'pochta'   => fn() => $this->russianPost->calculate($address, $weight, $dimensions),
    ])->map(function ($calculator, $carrier) {
        try {
            return $calculator();
        } catch (\Exception $e) {
            logger()->warning("Shipping calculator error: $carrier", ['error' => $e->getMessage()]);
            return [];
        }
    })->flatten(1)->sortBy('cost')->values();

    return $results->toArray();
}

Ниже — сравнение популярных служб доставки для интеграции.

Служба Скорость доставки (дни) Зоны покрытия Сложность API Комиссия
СДЭК 1–5 Города РФ, СНГ Низкая По тарифам
Boxberry 2–7 Города РФ, СНГ Средняя По тарифам
Почта России 3–14 Все регионы РФ Высокая Низкая

Что такое объёмный вес и как он влияет на стоимость?

Многие службы считают оплачиваемый вес как максимум из фактического и объёмного. Согласно правилам СДЭК, оплачиваемый вес равен максимуму из фактического и объёмного. Объёмный вес — это расчётный вес, основанный на габаритах. Для воздушной доставки коэффициент 6000 см³/кг, для морской — 1000 см³/кг. Если этого не учесть, расценки будут занижены. Пример: посылка весом 2 кг с габаритами 50×40×30 см даёт объёмный вес 60000/5000=12 кг — платить придётся за 12 кг.

Оптимизация расчётов через кеширование

Запросы к API служб доставки медленные (200–800 мс) и часто платные. Кешируем по ключу из города отправления, города назначения и веса. Тарифы меняются редко, поэтому кеш на 30 минут — оптимален. При обновлении тарифов инвалидируем по паттерну.

Интерфейс калькулятора: реактивный компонент

На странице товара или корзины — компактный блок с полем ввода города и списком методов с ценами и сроками. Без перезагрузки страницы:

const ShippingCalculator = () => {
  const [city, setCity] = useState('');
  const [options, setOptions] = useState([]);
  const [loading, setLoading] = useState(false);

  const calculate = useMemo(
    () =>
      debounce(async (cityValue) => {
        if (cityValue.length < 3) return;
        setLoading(true);
        try {
          const res = await fetch('/api/shipping/calculate', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ city: cityValue, cart_id: cartId }),
          });
          const data = await res.json();
          setOptions(data.options);
        } finally {
          setLoading(false);
        }
      }, 600),
    [cartId]
  );

  return (
    <div className="shipping-calculator">
      <input
        value={city}
        onChange={(e) => { setCity(e.target.value); calculate(e.target.value); }}
        placeholder="Введите ваш город"
      />
      {loading && <Spinner />}
      {options.map((opt) => (
        <ShippingOption key={opt.id} option={opt} />
      ))}
    </div>
  );
};

Дебаунс на 600 мс — не стреляем запросами после каждого символа.

Сколько времени занимает разработка?

  1. Аналитика — сбор требований, определение списка служб доставки, тарифных зон.
  2. Проектирование — выбор стека (Laravel/PHP + React/Next.js), проектирование схемы базы.
  3. Реализация — написание калькулятора, интеграция с API, разработка UI-компонента.
  4. Тестирование — проверка 100+ сценариев (разные города, веса, ошибки API).
  5. Деплой и мониторинг — настройка кеширования, алёртов при сбоях.

Ориентировочные сроки:

  • Калькулятор с одной службой по фиксированным тарифам — 2–3 дня.
  • С реальным API одной службы — 3–5 дней (включая обработку ошибок и кеширование).
  • Агрегатор на 3–5 служб с интерфейсом выбора — 2–3 недели.

Экономия клиентов на доставке после внедрения агрегатора составляет в среднем 20–30%, а инвестиции окупаются за 2–3 месяца. При значительном обороте экономия может быть существенной. Свяжитесь с нами для предварительной оценки вашего проекта.

Что входит в результат

  • Документация: описание тарифных схем, схема базы, инструкция по добавлению новых служб.
  • Доступы к панели администратора для управления тарифами.
  • Обучение сотрудников: как изменять тарифы, добавлять зоны.
  • Техническая поддержка в течение месяца после запуска.

Получите консультацию инженера: мы поможем выбрать оптимальную архитектуру и реализуем калькулятор за 2–3 недели.

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

Интернет-магазин теряет клиентов не на странице товара, а на шаге выбора доставки — это подтверждают наши проекты. Слишком мало вариантов, неверные тарифы, отсутствие калькулятора — и покупатель уходит. По данным 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 недели пост-релизного мониторинга и исправлений
Этап Длительность
Аудит требований (какие службы, сценарии, трекинг) 2–3 дня
Выбор архитектуры и реализация бэкенда 1–2 недели
Кэширование ПВЗ + тарифов 2–3 дня
Виджет на фронтенде (карта, список, фильтры) 1–2 недели
Тестирование с реальными заявками в тестовом режиме 3–5 дней
Деплой и сопровождение 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.

Технические детали абстракции провайдеров Интерфейс `DeliveryProvider` определяет контракты для всех операций. Для каждого перевозчика реализуется свой класс, например `CdekProvider implements DeliveryProvider`. В конструктор передаются конфиги (ключи, URL, настройки кэша). Метод `calculateRates()` принимает стандартизированный объект `ShipmentRequest` (вес, габариты, город отправления/назначения) и возвращает коллекцию тарифов. Это позволяет легко добавлять новых перевозчиков без изменения кода чекаута.

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

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

Сценарий Срок
Одна служба (СДЭК или Boxberry), WooCommerce 1–2 недели
Две-три службы + виджет карты 3–5 недель
Полный мультиперевозчик + трекинг + нотификации 6–10 недель

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

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

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

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