Тарифы перевозчика пропали после обновления приложения? Изменение доставки в Shopify 2026-10: что произошло и как исправить

Вчера тарифы работали, сегодня нет. Товары не менялись, адрес верный, а приложение с тарифами перевозчика в админке по-прежнему показывает зелёный Active. Единственное, на что можно указать: несколько дней назад приложение обновилось. В таком случае причина в изменении платформы, а не в сбое приложения.

Такую последовательность объясняет изменение API. 26 июня 2026 Shopify опубликовал несовместимое изменение для Admin GraphQL API версии 2026-10: carrier service, созданный через API, больше не добавляется в профиль доставки General магазина автоматически. Теперь он регистрируется и остаётся как есть, и чекаут не запрашивает у него тарифы, пока его явно не привязать.

Что именно изменилось в версии API 2026-10

До 2026-10 создание активного carrier service через carrierServiceCreate (или REST-аналог) делало две вещи: регистрировало сервис и добавляло его в подходящие зоны профиля доставки General магазина. Вторая часть выполнялась автоматически, поэтому большинство магазинов даже не знали, что она происходит. Формулировка самого Shopify для нового поведения прямая: создание carrier service теперь «только регистрирует carrier service», а платформа «больше не добавляет этот carrier service в профиль доставки General или в любые его зоны доставки по умолчанию». Без дополнительного шага «продавцы не увидят тарифы от вновь созданных carrier services на чекауте».

Две детали определяют, касается ли это вас вообще.

• Это касается созданных сервисов, а не существующих. Carrier service, который уже привязан к профилю, это изменение не отвязывает. Тарифы пропадают, когда приложение создаёт сервис заново (при переустановке или пересоздании сервиса) на версии 2026-10.
• Это зависит от версии. Shopify говорит, что более старые поддерживаемые версии API сохраняют прежнее поведение с автоматическим добавлением, пока их не отключат. Поэтому конкретный магазин сталкивается с этим в день, когда его приложение переходит на 2026-10 или новее. Вот почему это выглядит как «после обновления приложения», а не как сбой всей платформы в один день.

Почему это похоже на обновление приложения: обычно так и есть

Приложения регулярно повышают версию Admin API, на которой работают, а Shopify со временем требует этого по мере вывода из эксплуатации старых версий. В тот момент, когда приложение, управляющее carrier service, переходит на 2026-10, любой carrier service, который оно создаёт после этого, больше не привязывается автоматически. Если шаг привязки в приложение так и не добавили, потому что годами в нём не было нужды, изменение проявилось после обновления, а само приложение не обязательно сломано. Оно делает ровно то, что говорит новая спецификация API.

Та же картина возникает, когда сервис пересоздаётся, а не обновляется. Переустановка, повторная авторизация или пересборка приложения могут заменить старую регистрацию новой. Новый сервис ещё не привязан, а прежний, с привязкой, уже удалён. С точки зрения продавца это один carrier service, который перестал работать. В API это другая запись.

Есть и другая, независимая причина отсутствия тарифов: план магазина. Его стоит исключить, потому что симптом тот же. Для carrier services нужен план Advanced или выше, либо план Shopify с годовой оплатой или дополнением carrier-service, либо магазин для разработки. Shopify прямо пишет, что если магазин меняет план и больше не соответствует одному из этих условий, «связь магазина с carrier service деактивируется».

Пятиминутная проверка, которая покажет, какой у вас случай

Не начинайте с пересборки чего-либо. Сначала выясните, какой у вас случай: исправление в каждом разное.

Что вы находите	Что это значит	Где исправлять
Рассчитанного перевозчиком тарифа нет в зоне в Settings > Shipping and delivery	Шаг привязки 2026-10 был пропущен	Добавьте тариф в профиль заново: в админке или через API
Тариф в профиле есть, но callback приложения падает	Shopify переключается на запасной вариант, потому что endpoint тарифа выдал ошибку или не уложился в тайм-аут	Исправьте callback, затем проверьте заново
Сервис вообще не отображается в приложении	Carrier service удалили или заменили	Создайте его заново, затем привяжите
Недавно изменился план магазина	Связь деактивирована из-за плана	Повысьте план или добавьте нужную функцию, затем привяжите заново
Всё выглядит правильно, но пусты только некоторые зоны	Тариф привязан не к тому профилю или не к той зоне	Перенесите его в профиль, который покрывает эти товары

Как это исправить

Путь первый: продавец добавляет тариф в админке. Этот путь Shopify рекомендует в первую очередь. В Settings > Shipping and delivery откройте профиль доставки, который покрывает затронутые товары, откройте нужную зону и добавьте тариф с расчётом через перевозчика или приложение, выбрав carrier service. Справка Shopify описывает профили и зоны доставки как контейнер, который определяет, к каким товарам применяется правило, поэтому выбор профиля важен не меньше самого тарифа.

Путь второй: привязать программно. Для всего, что выходит за пределы одного профиля, используйте API профилей доставки: добавьте рассчитанный перевозчиком тариф в нужный профиль и зону из приложения. Shopify называет именно это вторым вариантом в changelog. Если ваше приложение пишет в профили доставки, которыми управляет продавец, проверьте также changelog за февраль 2026 о вариантах доставки в профилях доставки: он требует, чтобы приложения, пишущие в профили под управлением продавца, перешли на новый API записи, чтобы избежать неожиданного поведения.

Подтвердите это реальным чекаутом, а не скриншотом. Задайте адрес доставки в затронутой зоне, дойдите до чекаута и убедитесь, что вариант появляется с ожидаемым названием и ценой. Тариф, который есть в админке, и тариф на чекауте можно считать одним и тем же только после этой проверки.

Поставьте резервные тарифы до того, как что-то менять. Если рассчитанный тариф не отдаётся (ответ 40x/50x, тайм-аут или пустой массив), Shopify показывает резервные тарифы, только если они есть и нет другого подходящего тарифа. Фиксированный резервный тариф помогает завершить чекаут, если перевозчик не вернул цену.

Что должен делать callback, в коде

Carrier service это публичный POST-endpoint, который Shopify вызывает на чекауте, передавая точку отправления, назначение и товары, и он должен ответить JSON-массивом тарифов одним ответом. Цена указывается в минорных единицах валюты, поэтому "total_price": "500" это 5,00 в валюте магазина. Пустой массив со статусом 20x означает «для этой корзины тарифа нет»; ответ 404 говорит Shopify использовать резервные тарифы. Повторной попытки нет: первый ответ должен сработать, уложившись в тайм-аут, который сокращается с ростом числа запросов (10 секунд при менее чем 1500 запросов в минуту, вплоть до 3 секунд при более чем 3000), а одинаковые запросы кэшируются на 15 минут.

Сам вызов создания по форме не изменился, из него вынесен только шаг привязки:

mutation CreateCarrierService($input: DeliveryCarrierServiceCreateInput!) {
  carrierServiceCreate(input: $input) {
    carrierService { id name callbackUrl active }
    userErrors { field message }
  }
}

{
  "input": {
    "name": "Regional delivery",
    "callbackUrl": "https://rates.example.com/rates",
    "supportsServiceDiscovery": true,
    "active": true
  }
}

На версии API 2026-10 этот вызов возвращает сервис и регистрирует его, но не привязывает к профилю. Привязка это отдельная запись: обновление профиля выставляет carrier service как поставщика тарифов (DeliveryParticipant, который содержит id carrierService) внутри определения метода для нужной зоны, либо продавец добавляет его вручную.

Как я проверяю это на реальных внедрениях

Я делал именно такое приложение для тарифов доставки, поэтому этот сбой мне знаком не по теории. Для ритейлера клубной и школьной экипировки встроенные настройки доставки не поддерживали нужное правило: заказ из одной коллекции клуба или школы отправляется бесплатно как самовывоз из этого клуба или школы, а заказ из смешанной корзины оплачивает доставку по цене, заданной зоной. Я сделал endpoint тарифов перевозчика, который вызывается на чекауте, определяет для каждой позиции её коллекции и применяет правило. В нём есть движок правил с приоритетами по коллекциям, суммам корзины, тегам клиентов и стране назначения, профили цен с тарифами для отдельных стран, конструктор правил без кода, а также синхронизация товаров и коллекций.

Это приложение выросло в продуктовую версию, где больше всего внимания я уделил надёжности callback, от которого зависит чекаут: токен на 192 бита на каждый магазин вместо подделываемого заголовка магазина, ограничение частоты запросов на endpoint и безопасная обработка сбоев, чтобы неверное правило не ломало чекаут. В продуктовой линейке около 320 тестов. Подтверждено внедрение только у исходного клиента, в App Store приложения нет. Я говорю об этом прямо, чтобы не преувеличивать масштаб внедрения.

Из той работы я вынес простое правило: endpoint тарифов должен безопасно обрабатывать отказ, и как только он перестаёт это делать, магазин больше не может принимать деньги. Поэтому на «тарифы пропали» ответ никогда не в том, чтобы гадать про приложение: нужно определить, какой из пяти случаев выше произошёл, и исправить его причину.

“[He] made the perfect app for us and is brilliant to work with.”

— Клиент на Upwork, 2026. Перевод: «Сделал для нас идеальное приложение, с ним отлично работать».

Типичные ошибки

• Предположение, что приложение сломано. На 2026-10 приложение может быть полностью корректным и всё равно оставить тарифы непривязанными. Чините привязку, а не приложение.
• Повторное добавление тарифа без проверки существующего. Получатся два варианта в одной зоне. Удалите устаревшее определение метода, не добавляя второй вариант поверх него.
• Сначала смена плана. Смена плана может деактивировать связь. Проверьте требования к плану, прежде чем тратить день на приложение.
• Проверка только в админке. Админка показывает то, что существует, а чекаут показывает то, что Shopify фактически предложит. Проверяйте на чекауте.
• Пропуск резервных тарифов. Падающий callback без запасного варианта это чекаут, который отказывается завершаться, а это хуже отсутствующего варианта доставки.

Ограничения

• Это изменение поведения API, а не потеря данных. Ничего из прошлого не пересчитывается; вариант просто перестаёт предлагаться для вновь созданных сервисов, которые не привязаны.
• Сроки по версиям у приложений разные. Старые поддерживаемые версии сохраняют прежнее поведение до отключения, поэтому два магазина на одной версии приложения могут видеть разные результаты.
• Программная привязка не универсальна. Профили под управлением продавца и профили под управлением приложения записываются по-разному, и приложениям, которые пишут в профили под управлением продавца, может понадобиться новый API вариантов доставки.
• Требования к плану действуют независимо от привязки. Никакая привязка не поможет магазину, который больше не соответствует требованию плана для carrier services.
• Здесь речь о технической реализации, это не юридическая и не налоговая консультация.

Когда это не нужно

Если ваш магазин использует только фиксированные тарифы или тарифы по весу и никакого carrier service, это изменение вас не касается. Если пропал один тариф, а приложение везде показывает его привязанным, перед вами падающий callback или проблема с резервными тарифами, а не изменение 2026-10. А если у вас ровно одна зона и один тариф в магазине, который вы можете править сами, путь через админку займёт минуты. Платить за это кому-либо было бы неверным решением, и я так и скажу.

Могу сделать это для вас

Это ситуация Штатные настройки доставки не выражают ваши правила: собственные тарифы доставки на чекауте.

Всё начинается с бесплатного обсуждения: опишите задачу, и я определю, что это: шаг привязки 2026-10, падающий callback или смена плана. Причину определяю до любых изменений.

Обычный путь: повторная привязка пропавшего тарифа перевозчика по профилям одного магазина это Focused Fix от 30 000 ₽. Разработка или повышение надёжности самой логики правил доставки (правила по коллекциям, корзине и направлению, безопасный callback, привязка в коде) это Custom Engineering Project от 100 000 ₽. Если пока неясно, какой у вас случай, Working Session (10 000 ₽) определяет причину по одному вопросу до того, как что-либо менять.

Опишите задачу.