На прошлой неделе мне написал владелец интернет-магазина промышленных смазок. Человек продаёт масла, гидравлические жидкости, антифризы — тяжёлый, габаритный товар, который нужно доставлять по всей России. И вот что он рассказал: у него на сайте стоит пять отдельных плагинов для доставки. Один для СДЭК, один для Boxberry, один для Деловых Линий, ещё один для Почты России, и последний — для КИТ. Каждый плагин стоит от трёх до десяти тысяч рублей в год. Каждый обновляется по своему графику. Каждый имеет свой интерфейс настроек. И вот он сидит и думает — неужели нельзя сделать так, чтобы всё это работало из одного места? Чтобы покупатель на чекауте видел все варианты доставки разом, мог выбрать пункт выдачи на карте, а не копался в бесконечных радиокнопках?
Я слушал его и понимал, что это не уникальная ситуация. Это боль, с которой сталкивается практически каждый владелец WooCommerce-магазина в России. И чем крупнее магазин, тем острее эта боль. Потому что пять плагинов — это не просто пять подписок. Это пять потенциальных точек отказа. Пять разных команд разработчиков, которые могут забросить свой продукт или выпустить обновление, ломающее совместимость с последней версией WordPress. Это пять разных стилей отображения на чекауте, которые не согласуются между собой и создают у покупателя ощущение, что сайт собран из кусков на скотче.
Когда мы проектировали модуль доставки для COS WP Woo, мы исходили из простой идеи: один плагин — все перевозчики. Не агрегатор, который берёт с тебя комиссию за каждый заказ. Не универсальная обёртка, которая ломается при любом изменении API транспортной компании. А полноценная прямая интеграция с API каждого перевозчика, объединённая единым программным интерфейсом. Звучит просто? На практике — это месяцы работы, сотни часов тестирования и десятки нюансов, о которых я хочу рассказать.
Но давайте начнём не с технических деталей, а с экономики. Потому что в конечном итоге владельца магазина интересует не то, как красиво мы спроектировали архитектуру, а сколько денег он сэкономит и сколько проблем исчезнет из его повседневной жизни.
Арифметика, которая говорит сама за себя
Давайте посчитаем. Плагин для СДЭК — от пяти тысяч рублей в год за нормальную версию с поддержкой API v2. Boxberry — примерно столько же, может чуть дешевле, тысячи три-четыре. Деловые Линии — тут вариантов меньше, хорошие плагины начинаются от шести тысяч. Почта России — ещё три-пять тысяч. КИТ — совсем мало кто делает, но когда делает, просит пять-семь тысяч, потому что рынок маленький и конкуренции почти нет. Итого — от пятнадцати до пятидесяти тысяч рублей в год только на плагины доставки. И это без учёта времени, которое тратит ваш технический специалист (или вы сами) на то, чтобы всё это настроить, синхронизировать и поддерживать в рабочем состоянии.
Но деньги — это ещё не самое страшное. Самое страшное — это конфликты. Я помню случай, когда у одного нашего клиента после обновления WordPress до 6.5 перестали работать сразу два плагина доставки из пяти. Просто перестали. Разработчики одного ответили через неделю, второго — через три недели. Всё это время магазин работал с ограниченными вариантами доставки, терял заказы и получал негативные отзывы. Потому что покупатель не будет разбираться, почему на чекауте нет его любимой транспортной компании — он просто уйдёт к конкуренту.
Есть ещё один момент, о котором мало кто говорит. Каждый плагин доставки добавляет свои скрипты и стили на страницу чекаута. Один подключает jQuery-виджет для карты, другой — свой React-компонент, третий — ещё что-нибудь. В итоге страница чекаута загружается за четыре-пять секунд вместо положенных двух, и конверсия падает. Есть исследования, которые показывают, что каждая дополнительная секунда загрузки на чекауте снижает конверсию на семь-десять процентов. Умножьте это на ваш средний чек и количество заказов в месяц — цифры получаются впечатляющие.
Когда все перевозчики работают из одного плагина, это одна загрузка скриптов, одна карта, один AJAX-запрос на расчёт стоимости. Не пять запросов к пяти разным API, а один запрос к вашему серверу, который уже на бэкенде параллельно опрашивает все нужные API и возвращает консолидированный результат. Разница в скорости — колоссальная.
Как мы подошли к архитектуре: один интерфейс — все перевозчики
Знаете, что отличает хорошую инженерную систему от плохой? Хорошая система спроектирована так, что добавление нового элемента не ломает существующие. Когда мы начали проектировать модуль доставки, первое, что мы сделали — определили общий контракт для всех перевозчиков. В программировании это называется интерфейс, и наш CarrierInterface описывает ровно четыре вещи, которые должен уметь каждый перевозчик: сообщить свой код и название, рассчитать стоимость доставки, вернуть список пунктов выдачи и проверить, настроены ли API-ключи.
Почему это важно для вас как для владельца магазина? Потому что это означает, что все перевозчики работают абсолютно одинаково с точки зрения системы. Покупатель на чекауте видит единообразную таблицу, где для каждого перевозчика показана стоимость, срок доставки, есть ли доставка до двери или до пункта выдачи. Не нужно разбираться в разных интерфейсах разных плагинов. Всё выглядит как единое целое, потому что оно и является единым целым.
Мы реализовали пять перевозчиков: СДЭК, КИТ, Деловые Линии, Почта России и Boxberry. Каждый из них — это отдельный класс, который реализует общий интерфейс. CdekCarrier работает с API СДЭК версии 2.0, использует OAuth-авторизацию и поддерживает два тарифа — доставка до пункта выдачи и доставка курьером до двери. KitCarrier интегрируется с API КИТ Авто, который особенно актуален для межгородских перевозок тяжёлых и габаритных грузов. DellineCarrier работает с Деловыми Линиями — одной из крупнейших транспортных компаний России, которая незаменима, если вы отправляете паллеты или крупногабаритные товары. PostRussiaCarrier подключается к API Почты России через otpravka-api.pochta.ru и рассчитывает стоимость для посылок, бандеролей, EMS и курьерской доставки. И наконец, BoxberryCarrier работает с API Boxberry, который особенно популярен в сегменте небольших и средних посылок.
Вот тут я хочу остановиться и объяснить, почему мы выбрали прямую интеграцию с API, а не агрегатор. На рынке есть решения вроде eShopLogistic, которые выступают посредником между вашим магазином и транспортными компаниями. Идея красивая — вы подключаете один сервис и получаете доступ ко всем перевозчикам через единый API. Мы сами использовали такой подход на одном из проектов и столкнулись с рядом проблем, которые заставили нас пересмотреть стратегию.
Первая и самая очевидная проблема — это дополнительная точка отказа. Когда между вашим магазином и СДЭК стоит ещё один сервис, любой сбой на стороне этого сервиса означает, что все ваши перевозчики одновременно перестают работать. Мы столкнулись с этим дважды за полгода — агрегатор лежал по несколько часов, и весь чекаут был парализован. При прямой интеграции, если СДЭК API не отвечает, все остальные перевозчики продолжают работать. Покупатель просто не увидит варианты СДЭК, но сможет выбрать Boxberry или Деловые Линии.
Вторая проблема — скорость. Запрос через агрегатор идёт так: ваш сервер → агрегатор → API перевозчика → агрегатор → ваш сервер. Это дополнительные сто-двести миллисекунд на каждый запрос, которые складываются в ощутимую задержку на чекауте. При прямой интеграции ваш сервер напрямую обращается к API перевозчика, и ответ приходит быстрее.
Третья проблема — актуальность данных. Агрегаторы не всегда мгновенно подхватывают изменения в API транспортных компаний. Когда СДЭК обновил свой API до версии 2.0, некоторые агрегаторы ещё месяцами работали на старой версии и возвращали неточные данные по стоимости и срокам. При прямой интеграции вы работаете с самой свежей версией API и получаете самые точные расчёты.
Честно говоря, у прямой интеграции есть и минус — это сложность поддержки. Когда каждый перевозчик обновляет свой API, нам нужно обновить соответствующий класс в нашем плагине. Но именно для этого и существует единый интерфейс CarrierInterface — изменения в одном перевозчике никак не затрагивают остальных. Мы можем спокойно обновить CdekCarrier, не трогая BoxberryCarrier, и всё продолжит работать.
А что если посмотреть на это ещё с одной стороны? Представьте, что завтра на рынке появляется новая транспортная компания, которая предлагает отличные тарифы в ваш регион. С нашей архитектурой добавление нового перевозчика — это создание одного нового класса, который реализует тот же интерфейс. Никаких изменений в существующем коде, никаких рисков что-то сломать. Создали класс, зарегистрировали его в системе — и он уже появился на чекауте рядом с остальными. Попробуйте добиться такого с пятью отдельными плагинами от разных разработчиков.
ФИАС, адреса и почему строковый поиск — это путь в никуда
Есть одна тема, о которой разработчики плагинов доставки обычно стыдливо молчат. Это проблема определения города получателя. Казалось бы, что тут сложного — покупатель ввёл город, система передала его транспортной компании, получили расчёт. Но на практике всё гораздо веселее.
Попробуйте ввести «Челябинск» в разные API — всё будет работать прекрасно. А теперь попробуйте «Нижний Тагил». Или «Набережные Челны». Или «Ростов-на-Дону». У каждой транспортной компании свой справочник городов, свой формат названий, свои коды. СДЭК использует свои внутренние коды городов. Boxberry — свои. Деловые Линии — свои терминалы. Почта России работает по почтовым индексам. И вот вы уже пишете конвертеры из одного формата в другой, обрабатываете различия в написании (через «ё» или через «е», с дефисом или без, в каком порядке идут слова), и это превращается в бесконечный кошмар поддержки.
Мы решили эту проблему принципиально. Вместо того чтобы сопоставлять строковые названия городов между разными API, мы используем ФИАС — Федеральную информационную адресную систему. Это официальный классификатор адресов Российской Федерации, где каждому населённому пункту присвоен уникальный идентификатор — GUID. Этот идентификатор не зависит от того, как вы напишете название города — кириллицей, латиницей, с опечаткой или без.
В нашей системе каждый класс доставки (shipping class) в WooCommerce привязан к ФИАС-коду города отправки. Это означает, что когда товар отправляется с определённого склада, система точно знает, из какого города он отправляется — не по строковому названию, а по уникальному идентификатору в федеральном справочнике. Для города получателя мы используем комбинацию методов — ФИАС-код, если он доступен, или почтовый индекс для Почты России, или внутренний код города для тех перевозчиков, которые предоставляют API поиска по городам.
Я долго думал, почему другие разработчики не используют этот подход. Ответ, как обычно, простой — это сложнее реализовать. Строковый поиск — это одна строчка кода. ФИАС-интеграция — это отдельный класс ShippingFias, который добавляет колонку с ФИАС-кодом в настройки классов доставки WooCommerce, сохраняет эти коды в метаданных таксономии и предоставляет их при расчёте доставки. Но результат стоит усилий — расчёт работает корректно для любого города России, без ошибок из-за различий в написании названий.
Вот конкретный пример из нашей практики. Один из клиентов продавал масла по всей России и столкнулся с тем, что при отправке в город Ноябрьск старый плагин СДЭК не мог найти этот город, потому что в его внутреннем справочнике город был записан как «Ноябрьск (Тюменская обл.)», а покупатель ввёл просто «Ноябрьск». Заказ зависал, менеджер звонил клиенту, уточнял адрес, вручную создавал заявку на сайте СДЭК. Умножьте это на двадцать-тридцать таких случаев в месяц — и вы поймёте масштаб проблемы. С ФИАС этой проблемы просто не существует, потому что «Ноябрьск» имеет один и только один GUID в федеральном справочнике, и все перевозчики получают именно его.
Есть ещё один аспект работы с адресами, о котором стоит упомянуть — это группировка товаров по складам отправления. В реальном бизнесе, особенно в B2B-сегменте, товары часто хранятся на разных складах. У одного из наших клиентов масла Shell лежали на складе в Челябинске, масла Лукойл — на складе в Нерсоне, а гидравлические жидкости — на складе маркетинговой продукции в другом месте. Каждый склад — это свой класс доставки в WooCommerce с привязанным ФИАС-кодом. Когда покупатель добавляет в корзину товары с разных складов, наша система автоматически группирует их и рассчитывает стоимость доставки отдельно для каждой группы. Покупатель видит, что за масла Shell доставка стоит столько-то, а за масла Лукойл — столько-то, и суммарная стоимость — вот такая. Прозрачно, понятно, без скрытых сюрпризов.
Чекаут, которым можно гордиться: матрица доставки и карта ПВЗ
Теперь давайте поговорим о том, что видит покупатель. Потому что можно построить идеальную архитектуру на бэкенде, но если на чекауте всё выглядит как таблица в Excel из 1998 года, никому от этого не станет лучше.
Мы построили матрицу доставки — таблицу, в которой покупатель видит все доступные варианты от всех подключённых перевозчиков. Для каждого варианта показывается название перевозчика, тип доставки (до двери или до пункта выдачи), стоимость и ориентировочный срок. Покупатель выбирает подходящий вариант одним кликом. Если он выбрал доставку до пункта выдачи, открывается карта с отмеченными пунктами того перевозчика, которого он выбрал. На карте можно найти ближайший пункт выдачи, посмотреть его адрес и график работы.
Знаете, что меня всегда раздражало в существующих плагинах доставки? Они показывают варианты последовательно — сначала все варианты СДЭК, потом все варианты Boxberry, потом все варианты Почты России. И покупатель должен сам скроллить этот бесконечный список, сравнивая цены и сроки. В нашей матрице всё наглядно — все перевозчики рядом, сравнивай и выбирай. Я считаю, что это существенно влияет на конверсию, хотя точных A/B-тестов именно на этот элемент мы пока не проводили. Но логика подсказывает: чем проще человеку принять решение, тем быстрее он оформит заказ.
Отдельно стоит сказать про техническую реализацию матрицы на чекауте. WooCommerce предоставляет стандартный механизм Shipping Methods, и наш модуль регистрирует единый метод доставки с идентификатором wpaic_shipping. Один метод, а не пять отдельных. Это означает, что все перевозчики работают в рамках одного WooCommerce Shipping Method, корректно интегрируются с зонами доставки WooCommerce и не конфликтуют с другими методами доставки, которые вы можете использовать (например, самовывоз или бесплатная доставка от определённой суммы заказа).
Расчёт стоимости происходит в реальном времени через API каждого перевозчика. Когда покупатель вводит свой адрес на чекауте, наш плагин отправляет параметры заказа (вес, габариты, объявленная стоимость, город получателя) в каждый подключённый API и получает обратно стоимость и сроки доставки. Результаты кешируются на десять минут — это настраиваемый параметр — чтобы не нагружать API избыточными запросами, если покупатель обновляет страницу или меняет количество товаров в корзине.
Здесь я хочу рассказать об одном техническом нюансе, который может показаться мелочью, но на практике стоил нам нескольких дней отладки. В WooCommerce данные сессии — это строки. Когда вы получаете вес товара из сессии, вы получаете строку «1.5», а не число 1.5. И если вы передадите эту строку в функцию round() в PHP 8.x без явного приведения к типу float, вы получите ошибку. Звучит банально, но представьте, что у вас пять перевозчиков и каждый из них получает данные из сессии — если хотя бы один разработчик забудет про приведение типов, расчёт стоимости сломается. В нашем коде каждое числовое значение из параметров явно приводится к float перед математическими операциями. Мелочь? Да. Но именно из таких мелочей складывается стабильная работа.
А вот ещё один момент, который я считаю принципиально важным. Расчёт доставки рендерится через хук woocommerce_review_order_before_payment, а не через before_order_review, как советуют многие гайды. Почему? Потому что before_order_review не работает корректно с block-темами WordPress, которые становятся стандартом. Мы потратили немало времени, разбираясь, почему на одном из тестовых сайтов с темой Twenty Twenty-Five матрица доставки просто не появлялась, пока не обнаружили, что хук before_order_review в block-темах срабатывает до того, как форма чекаута полностью отрендерена. Переключение на before_payment решило проблему. Таких нюансов — десятки, и именно они отличают плагин, который «вроде работает», от плагина, который работает надёжно.
Трекинг: от создания заказа до вручения посылки
Доставка — это не только расчёт стоимости и выбор перевозчика на чекауте. Это ещё и то, что происходит после оформления заказа. Покупатель хочет знать, где его посылка, когда она приедет и что делать, если что-то пошло не так. И здесь у большинства WooCommerce-магазинов начинается хаос.
Типичный сценарий выглядит так: менеджер оформляет отправление на сайте транспортной компании, получает трек-номер, копирует его, вставляет в примечание к заказу в WooCommerce, и может быть — может быть! — отправляет покупателю email с этим номером. Покупатель получает письмо, переходит на сайт перевозчика, вводит трек-номер, проверяет статус. Если перевозчик другой, ему нужно знать, на каком сайте проверять. Если в заказе товары от нескольких перевозчиков (помните про группировку по складам?), покупателю нужно отслеживать несколько трек-номеров на разных сайтах.
Мы интегрировали трекинг отправлений прямо в систему. Когда менеджер вводит трек-номер в карточке заказа, покупатель видит его в своём личном кабинете на сайте магазина. Не нужно переходить на сторонние сайты, не нужно запоминать, какой перевозчик доставляет какую часть заказа. Всё в одном месте — название перевозчика, трек-номер, текущий статус. При изменении статуса отправления покупатель получает email-уведомление.
Я часто слышу вопрос: «А зачем это делать в плагине, если покупатель и так может проверить трек на сайте перевозчика?» Ответ простой — потому что это про клиентский опыт. Магазин, в котором вся информация доступна в одном месте — в личном кабинете — воспринимается как более профессиональный и надёжный. Покупатель не думает «я заказал на каком-то сайте, а доставляет СДЭК». Он думает «я заказал в этом магазине, и они позаботились о том, чтобы мне было удобно отслеживать доставку». Это мелочь, которая формирует лояльность.
А теперь давайте поговорим о стороне продавца. Если у вас интернет-магазин с десятками заказов в день, управление доставкой превращается в рутину. Трек-номера, статусы, уведомления — всё это нужно контролировать. Наш модуль доставки интегрируется с модулем 1С, который тоже является частью COS WP Woo. Это означает, что статусы отправлений могут синхронизироваться с вашей учётной системой. Менеджер в 1С видит, что заказ отправлен, какой у него трек-номер, какой перевозчик, какой текущий статус. Не нужно переключаться между несколькими системами — всё синхронизировано.
Я знаю, что многие скептически относятся к идее «всё в одном плагине». И я понимаю этот скепсис. Универсальные решения часто проигрывают специализированным в глубине проработки. Но тут есть важный нюанс: мы не делаем один плагин для всего на свете. Мы делаем один плагин для экосистемы WooCommerce-магазина, где все модули работают вместе и обмениваются данными. Модуль доставки знает про модуль 1С. Модуль 1С знает про модуль B2B. Модуль B2B знает про модуль email-уведомлений. Это не набор разрозненных функций, запиханных в один ZIP-файл — это интегрированная система, где каждый модуль усиливает остальные.
Почта России — перевозчик, который вечно стоял особняком
Я отдельно хочу поговорить про Почту России, потому что её интеграция — это отдельная история, полная боли и радости одновременно. Почта России — это крупнейшая логистическая сеть страны. Более сорока двух тысяч отделений. Доставка в любой населённый пункт, включая деревни и посёлки, куда ни один коммерческий перевозчик не поедет. Для многих магазинов Почта России — это единственный способ доставить товар в отдалённые регионы.
При этом API Почты России — это, мягко говоря, своеобразная вещь. У них есть два API: калькулятор тарифов (публичный, без авторизации) и API отправки (с авторизацией через токен и логин). Калькулятор тарифов работает по почтовому индексу — вы передаёте индекс отправки, индекс получения, вес, тип отправления и объявленную ценность, и получаете стоимость. Звучит просто, но дьявол, как всегда, в деталях.
Тип отправления — это то, что сбивает с толку большинство разработчиков. Посылка, бандероль, EMS, курьерская доставка — каждый тип имеет свой код, свои ограничения по весу и габаритам, свою тарифную сетку. Наш PostRussiaCarrier автоматически определяет оптимальный тип отправления на основе веса и объявленной стоимости заказа. Если посылка лёгкая — рассчитывает как бандероль (это дешевле). Если тяжёлая — как стандартную посылку. Если покупатель хочет быстрее — предлагает EMS или курьерскую доставку. Покупатель видит все доступные варианты с ценами и сроками и выбирает то, что ему подходит.
Отдельная история — это обработка ошибок. API Почты России может вернуть ошибку по совершенно неочевидной причине — например, потому что почтовый индекс относится к военной части или к закрытому территориальному образованию. В таких случаях наш плагин не показывает покупателю криптографическое сообщение об ошибке, а просто не отображает варианты Почты России, оставляя доступными других перевозчиков. Это кажется мелочью, но для покупателя разница огромная — между «Ошибка расчёта доставки, попробуйте позже» и нормально работающим чекаутом, где просто нет одного из вариантов.
И вот тут начинается самое интересное с точки зрения архитектуры. Помните, я говорил про единый интерфейс CarrierInterface? Каждый перевозчик в методе calculate() возвращает стандартизированный результат — статус успешности, цена, срок, текст ошибки (если есть) и код перевозчика. Это означает, что система обработки результатов абсолютно одинакова для всех перевозчиков. Если СДЭК вернул ошибку — отображаем остальных. Если Почта России вернула ошибку — отображаем остальных. Если все вернули успешный результат — показываем полную матрицу. Логика простая и надёжная, потому что она не зависит от специфики конкретного перевозчика.
СДЭК и Boxberry — два гиганта, которые должны дружить
СДЭК и Boxberry — это, пожалуй, два самых популярных перевозчика для интернет-магазинов в России. У СДЭК огромная сеть пунктов выдачи — более четырёх тысяч по стране. У Boxberry — свои преимущества, особенно в сегменте небольших посылок и в регионах, где СДЭК представлен слабо. Многие магазины подключают оба сервиса, чтобы дать покупателю максимальный выбор.
СДЭК перешёл на API v2.0, который использует OAuth-авторизацию. Это значит, что для получения доступа к API нужно сначала получить токен доступа, обменяв client_id и client_secret на временный bearer-токен. Наш CdekCarrier обрабатывает это автоматически — получает токен, кеширует его в WordPress transients, автоматически обновляет при истечении срока действия. Для вас как для пользователя это означает, что вы один раз вводите client_id и client_secret в настройках плагина и больше никогда об этом не думаете.
С Boxberry ситуация проще — у них авторизация через токен, который передаётся как параметр запроса. Но зато у Boxberry есть свои сложности с определением города. Boxberry использует свой внутренний справочник городов с собственными кодами. Наш BoxberryCarrier сначала резолвит город покупателя — находит его код в справочнике Boxberry по названию и почтовому индексу — и уже потом рассчитывает стоимость доставки. Если город не найден (что бывает в маленьких населённых пунктах), Boxberry просто не отображается в матрице доставки, и покупатель может выбрать другого перевозчика.
Я заметил интересную вещь за годы работы с доставкой: покупатели очень лояльны к «своему» перевозчику. Кто-то принципиально выбирает только СДЭК, потому что рядом с домом есть удобный пункт выдачи. Кто-то предпочитает Boxberry, потому что у них быстрее доставляют в его регион. Кто-то обожает Деловые Линии, потому что они надёжно доставляют тяжёлые грузы. И задача магазина — не навязывать покупателю конкретного перевозчика, а дать выбор. Чем больше вариантов — тем выше вероятность, что покупатель найдёт то, что ему подходит, и завершит заказ.
Но есть и другая сторона медали. Каждый дополнительный перевозчик — это дополнительные API-ключи, которые нужно получить и настроить. Для СДЭК нужно зарегистрировать договор и получить доступ к API. Для Boxberry — получить токен. Для Деловых Линий — заключить договор и получить API-ключ. Для Почты России — зарегистрироваться на otpravka.pochta.ru и получить токен авторизации. Для КИТ — аналогично. Мы не можем сделать эту часть за вас — это процесс между вами и транспортной компанией. Но мы можем — и делаем — предоставить в настройках плагина чёткие инструкции, где и как получить каждый ключ, с прямыми ссылками на страницы регистрации.
А знаете, что самое приятное? Метод is_configured() в каждом перевозчике проверяет, настроены ли API-ключи. Если нет — перевозчик просто не участвует в расчёте. Это означает, что вы можете подключить сначала только СДЭК и Boxberry, а потом, когда договоритесь с Деловыми Линиями и КИТ, добавить их — просто вбив ключи в настройках. Никаких перенастроек, никаких повторных тестов. Система автоматически подхватит новых перевозчиков и начнёт показывать их на чекауте.
КИТ и Деловые Линии — для тех, кто возит серьёзные грузы
Есть сегмент рынка, который СДЭК и Boxberry обслуживают не очень хорошо — это крупногабаритные и тяжёлые грузы. Канистра моторного масла 20 литров весит около 18 килограммов. Бочка 200 литров — это уже под 200 килограммов. Паллета с маслами — 500-800 килограммов. Для такого груза нужны перевозчики, которые специализируются на сборных грузах и имеют терминалы для приёма крупных отправлений.
КИТ (Компания Индустриальных Транспортировок) — один из лидеров в сегменте межгородских автомобильных грузоперевозок. У них более пятисот терминалов по России, и они отлично справляются с грузами от 20 до 20000 килограммов. Для наших клиентов, которые продают промышленные масла и смазки, КИТ часто оказывается оптимальным выбором по соотношению цена/скорость для межгородских отправок.
Деловые Линии — ещё один крупный игрок в этом сегменте, с более чем тысячей терминалов и подразделений по России. Их API позволяет рассчитать стоимость доставки как до терминала, так и до двери получателя, с учётом дополнительных услуг — страхования, жёсткой упаковки, подъёма на этаж.
Когда мы интегрировали КИТ и Деловые Линии, мы столкнулись с тем, что их API устроены совсем иначе, чем у СДЭК или Boxberry. У них другая модель авторизации, другой формат запросов и ответов, другая логика определения терминалов. Но именно в этом и заключается ценность единого интерфейса — все эти различия скрыты внутри конкретных классов-перевозчиков. Снаружи, для системы расчёта доставки, все перевозчики выглядят одинаково: вызываем calculate(), получаем цену и срок. Вызываем get_terminals(), получаем список пунктов выдачи. Всё единообразно, всё предсказуемо.
Для владельца магазина, который торгует тяжёлыми товарами, наличие КИТ и Деловых Линий в том же плагине, где уже стоят СДЭК и Boxberry — это не просто удобство. Это расширение географии доставки и снижение стоимости для конечного покупателя. Потому что для отправки 100-килограммового заказа через СДЭК стоимость может быть десять тысяч рублей, а через КИТ — три тысячи. И когда покупатель видит оба варианта на чекауте рядом, он делает осознанный выбор и не чувствует, что магазин пытается на нём заработать на доставке.
Я часто слышу от владельцев магазинов: «Зачем мне КИТ или Деловые Линии? У меня мелкие товары, СДЭК и Boxberry хватает». И в большинстве случаев это действительно так. Но вот что я заметил: как только магазин начинает расти и расширять ассортимент, рано или поздно появляются товары, для которых СДЭК и Boxberry — не лучший выбор. И если к этому моменту у вас уже есть плагин с поддержкой КИТ и Деловых Линий, вам нужно лишь получить API-ключи и вбить их в настройках. Если нет — вам нужно искать новый плагин, покупать его, настраивать, тестировать, и надеяться, что он не будет конфликтовать с существующими.
Кеширование и производительность: чтобы чекаут летал
Я уже упоминал кеширование, но хочу остановиться на этом подробнее, потому что это критически важная тема для любого интернет-магазина. Каждый запрос к API транспортной компании — это сетевой запрос, который занимает от двухсот миллисекунд до двух секунд, в зависимости от перевозчика и загруженности его серверов. Если у вас подключены пять перевозчиков и для каждого нужно рассчитать два варианта (курьер и пункт выдачи), это десять сетевых запросов. Последовательно — это десять-двадцать секунд ожидания на чекауте. Параллельно — это две-три секунды, но нагрузка на ваш сервер всё равно существенная.
Наш подход — кешировать результаты расчёта на десять минут (настраиваемый параметр cache_ttl). Ключ кеша формируется из параметров заказа: город отправки, город получения, вес, объявленная стоимость. Если покупатель обновил страницу или зашёл на чекаут повторно с тем же набором товаров — результаты расчёта отдаются из кеша мгновенно. Если он изменил количество товаров или адрес доставки — кеш инвалидируется и расчёт выполняется заново.
Десять минут — это разумный компромисс между актуальностью данных и производительностью. Тарифы транспортных компаний не меняются каждую минуту. Они могут измениться раз в день, раз в неделю или раз в месяц. Десятиминутный кеш гарантирует, что покупатель получит актуальную стоимость, но при этом чекаут не будет тормозить из-за избыточных запросов к API.
Есть ещё один момент, связанный с производительностью, о котором мало кто задумывается. Когда вы используете пять отдельных плагинов доставки, каждый из них подключает свои PHP-классы, свои хуки WordPress, свои AJAX-обработчики. Это дополнительная нагрузка на сервер при каждом запросе, даже если покупатель не находится на странице чекаута. В нашем плагине все перевозчики — это лёгкие PHP-классы, которые загружаются и инициализируются только когда они реально нужны, то есть при расчёте доставки. Они не добавляют хуки на каждую страницу сайта, не подключают скрипты на страницах, где доставка не нужна.
Что всё это значит для вашего бизнеса
Я начал эту статью с истории про владельца магазина смазок, и хочу вернуться к ней. После того, как он перешёл с пяти отдельных плагинов на наш модуль доставки, произошло несколько вещей. Экономия на подписках составила около тридцати тысяч рублей в год. Время загрузки чекаута сократилось с пяти секунд до полутора. Количество обращений в поддержку по поводу доставки упало процентов на сорок. И — что, пожалуй, самое важное — он перестал бояться обновлений WordPress, потому что теперь у него один плагин вместо пяти, и за его совместимость отвечает одна команда, а не пять разных разработчиков.
Но я не хочу создавать впечатление, что наше решение идеально для всех. Если у вас маленький магазин с двадцатью заказами в месяц и единственный перевозчик — СДЭК, вам, вероятно, достаточно бесплатного плагина для СДЭК. Наш модуль доставки раскрывается в полную силу, когда у вас несколько перевозчиков, несколько складов отправки, когда вам важна скорость чекаута и единообразие клиентского опыта. Когда вам нужна интеграция с 1С для синхронизации статусов. Когда вы продаёте и лёгкие товары (СДЭК, Boxberry, Почта России), и тяжёлые (КИТ, Деловые Линии) — и хотите, чтобы всё это работало как единый механизм.
Есть ещё один аргумент, о котором я задумался совсем недавно. Рынок транспортных услуг в России меняется. Появляются новые перевозчики, старые меняют условия, кто-то уходит из отдельных регионов. Когда у вас архитектура с единым интерфейсом перевозчика, адаптация к этим изменениям происходит быстро и безболезненно. Нужно добавить нового перевозчика? Создаём новый класс, реализующий CarrierInterface. Нужно отключить перевозчика? Убираем его API-ключи из настроек, и он просто перестаёт отображаться на чекауте. Нужно обновить интеграцию с перевозчиком, который изменил API? Обновляем один класс, остальные не трогаем. Это гибкость, которую невозможно получить с набором разрозненных плагинов.
Я долго размышлял, стоит ли писать эту статью, потому что тема доставки кажется скучной. Это не искусственный интеллект, не блокчейн, не какая-нибудь модная технология. Но знаете что — доставка напрямую влияет на деньги. На конверсию чекаута, на стоимость поддержки, на лояльность покупателей, на масштабируемость бизнеса. И когда ты находишь решение, которое делает доставку проще, быстрее и дешевле — это, может быть, не так красиво звучит на конференции, но это именно то, что нужно реальному бизнесу.
Мы продолжаем развивать модуль доставки. В планах — расширение списка перевозчиков, более глубокая интеграция с API для автоматического создания заявок, интерактивная карта с визуальным отображением всех пунктов выдачи на чекауте. Но уже сейчас то, что есть — пять перевозчиков, единый интерфейс, ФИАС-адреса, матрица на чекауте, трекинг и интеграция с 1С — покрывает потребности подавляющего большинства WooCommerce-магазинов в России.
И последнее. Мне часто говорят: «Всё в одном — это значит, что если плагин сломается, сломается всё». Справедливое опасение. Но давайте честно — если у вас пять отдельных плагинов и один из них сломался, часть вашего чекаута тоже сломана. А если сломались два из пяти — вы всё равно судорожно ищете решение. Разница в том, что с одним плагином у вас одна команда поддержки, один канал обратной связи, один процесс обновления. И если что-то идёт не так, вы знаете, куда обращаться. Вместо того чтобы разбираться, какой из пяти плагинов виноват в конфликте, вы пишете нам — и мы решаем проблему. Это не идеальный мир, но это мир, в котором проблемы решаются быстрее.
Попробуйте COS WP Woo — 14 дней бесплатно. Один плагин вместо пяти для доставки, плюс ещё сорок с лишним модулей для вашего WooCommerce-магазина. Подключите СДЭК, Boxberry, Деловые Линии, Почту России и КИТ за один вечер, а не за неделю. Настройте один раз — и забудьте про головную боль с доставкой.
