Покупатель выбрал пункт выдачи, увидел стоимость доставки и оплатил заказ. Для него всё уже решено. Для магазина работа только начинается: проверить комплектацию, оформить отправление, получить ярлык, передать коробку перевозчику и сообщать человеку, где его покупка. Если эти действия не связаны между собой, красивый виджет в корзине оставляет сотрудникам прежнюю ручную работу.
Мы в Гуси-Лебеди предлагаем разбирать интеграцию доставки по всему пути заказа. Ниже объясняем, как выбрать способ подключения, не перепутать товар с упакованной посылкой и принять результат по операциям, которые действительно нужны вашему магазину.
Что подключать: виджет, готовый модуль или API
Начните с простой записи: кто и в какой момент должен выполнить каждое действие. Покупатель выбирает доставку в корзине. Менеджер подтверждает наличие. Склад упаковывает покупку. После этого система или сотрудник оформляет отправление. Назначьте владельца каждому переходу, включая отмену заказа и возврат.
Виджет решает задачу выбора. Карта помогает найти ПВЗ, но сама по себе не доказывает, что магазин умеет передавать заказ, печатать ярлыки и получать статусы. В справке Яндекс Доставки отдельно описаны подключение системы и установка виджета. Там же указано, что виджет использует публичные тарифы. Договорную цену нельзя автоматически считать совпадающей с показанной на карте.
Готовый модуль связывает перевозчика с конкретной платформой. Проверьте совместимость с вашей версией CMS, используемой корзиной и способом оформления заказа. Затем сравните нужные операции с возможностями самого модуля. Наличие названия платформы в каталоге ещё не отвечает на вопрос, поддерживается ли ваш сценарий оплаты или отгрузки.
Прямая интеграция по API позволяет построить собственную последовательность действий. В официальном разделе СДЭК этот вариант рассматривается для самописных и существенно доработанных решений. Открытый интерфейс перевозчика не означает бесплатную разработку на стороне магазина: настройку, обработку ошибок и дальнейшее сопровождение нужно учитывать отдельно.
Если перевозчиков несколько, рассмотрите интегратор с единым интерфейсом. Но прочитайте модель сотрудничества: один технический вход не обязательно означает один договор на все доставки. Например, ApiShip описывает работу по прямым договорам магазина с курьерскими службами. Сравнивать решения лучше по поддерживаемым операциям, условиям подключения и ответственности за сбой, а не только по числу логотипов.
Эти требования стоит заложить ещё при проектировании интернет-магазина. Иначе выбор доставки на сайте и работа склада могут оказаться двумя отдельными проектами.
Из чего складывается корректный расчёт доставки
Представим условный магазин посуды. В корзине две чашки и чайник. Чашки можно положить в одну коробку, а чайник отправить отдельно. Сложить массу товаров недостаточно: для расчёта нужны сведения о том, как покупка поедет после упаковки. В этом примере заказ один, а грузомест два. Такая ситуация должна быть предусмотрена до запуска.
Разделяйте данные каталога и отправления. У товара есть артикул, количество и цена. У коробки есть собственные размеры, масса брутто и связь с помещёнными внутрь товарами. В документации метода создания заявки Яндекс Доставки эти сущности представлены отдельно: items и places. Для грузоместа размеры указаны в сантиметрах, масса брутто в граммах. У другого интерфейса единицы нужно проверять заново.
Проверьте преобразования на понятном примере: масса упакованной коробки 1,2 кг должна превратиться в 1200 граммов, если поле принимает граммы. Это учебный расчёт, а не ограничение перевозчика. Отдельно проверьте количество одинаковых товаров: пропущенное значение может изменить состав отправления, хотя название позиции выглядит верно.
Маршрут тоже должен быть однозначным. Запишите склад или точку отгрузки, выбранный ПВЗ либо полный адрес получателя, способ доставки и необходимые интервалы. Сохраняйте идентификатор выбранной точки, а не только строку с её адресом. При изменении города или состава корзины проверяйте, подходит ли прежний выбор к новому заказу.
У суммы перевозчика и суммы для покупателя могут быть разные правила. Магазин может компенсировать часть доставки, добавить согласованную наценку или предложить бесплатную доставку при выполнении условий. В настройке Яндекс Доставки в Tilda предусмотрена наценка фиксированной суммой или в процентах. Отразите вашу логику в корзине понятно и проверьте итог после применения скидки или изменения количества.
Если расчёт недоступен, не подставляйте ноль как будто доставка бесплатная. Предусмотрите честный ответ: предложить другой способ или согласовать стоимость с менеджером. Пользователь должен понимать условия до завершения оформления, а сотрудник видеть причину, по которой автоматический расчёт не состоялся.
Как довести заказ до отправления и не создать дубль
Определите событие, после которого можно оформлять доставку. Для одного процесса это подтверждённая комплектация, для другого согласованный менеджером заказ. Не выбирайте событие только потому, что его удобнее получить из сайта. Преждевременное создание отправления усложнит работу, если товара нет или покупатель изменил адрес.
Сохраняйте связь между номером заказа магазина и идентификатором отправления перевозчика. У выбранного предложения тоже может быть отдельный идентификатор и срок действия. В Яндекс Доставке метод получения офферов возвращает варианты доставки, а подтверждение оффера бронирует вариант и возвращает request_id созданного заказа. Проверяйте конкретный метод, а не выводите результат из слова «создание» в его названии.
Отдельно разберите неприятный сценарий: запрос ушёл, ответа нет. Тайм-аут не сообщает, успел ли перевозчик обработать операцию. Рекомендуем до повторного создания выяснять состояние первой попытки доступным способом и защищать операцию от дублирования. Поддержку ключа идемпотентности или поиска по вашему номеру нужно подтвердить в документации выбранного API; одинаковое поведение всем сервисам приписывать нельзя.
Договоритесь, как сотрудник увидит зависшую операцию и что сможет сделать дальше. Полезнее очередь заказов с причиной ошибки и историей попыток, чем незаметная запись в техническом журнале. При этом журнал не должен показывать секретный токен пользователю или раскрывать лишние данные получателя.
Статусы магазина и перевозчика сопоставляйте явно. «Заказ оплачен», «отправление оформлено», «передано перевозчику» и «вручено» обозначают разные события. Продумайте способ обновления: запрос информации или уведомления, если их поддерживает сервис. Для уведомлений предусмотрите повторную доставку события и поступление сообщений не по порядку. Это требования к вашей обработке, которые нужно проверить в реализации.
Отмена в магазине также требует понятного продолжения. Проверьте, можно ли ещё отменить отправление, кто принимает решение при отказе перевозчика и какое состояние увидит покупатель. Для возврата товара определите отдельный процесс: обратное движение посылки не должно автоматически превращать исходный заказ в новую продажу.
Как принимать интеграцию: пройти путь покупателя и склада
Проверяйте не только успешный ответ API. Возьмите согласованные тестовые данные и пройдите заказ от выбора доставки до состояния, которое должен увидеть менеджер. Если перевозчик предоставляет тестовый контур, используйте его для подходящих сценариев. Демонстрационный кабинет, тестовый API и реальная отгрузка решают разные задачи; результат одного не подменяет остальные.
- Обычный заказ. Адрес или ПВЗ сохраняются, сумма в корзине соответствует выбранным условиям, отправление связано с правильным заказом и видимо сотруднику.
- Изменение покупки. Добавление второй одинаковой позиции, смена города, скидка и разделение по коробкам дают ожидаемый пересчёт. Неподходящий прежний способ нельзя оформить молча.
- Сбой и повтор. Недоступный расчёт, потерянный ответ и повторное нажатие не приводят к незаметной бесплатной доставке или двум отправлениям. Сотрудник получает понятный следующий шаг.
- Работа после оформления. Подтверждение, ярлык, обновление состояния, отмена и возврат проходят по согласованному процессу. Проверяйте только реально поддерживаемые операции и фиксируйте исключения.
По каждому сценарию сохраните исходные условия, ожидаемый и фактический результат. Для приёмки важно не обещание «всё автоматически», а ответ на вопросы: что автоматизировано, где нужен человек и как магазин обнаружит остановку обмена.
Вместе с настроенной интеграцией передайте ответственному схему процесса, перечень подключений, правила восстановления и контакты поддержки. Тогда доставка будет понятной частью работы магазина, а не загадочной кнопкой, которую боятся трогать после первого сбоя.