Скрипт расчёта стоимости доставки на Тильде: как это сделать

Стоимость доставки - то немногое, что реально влияет на конверсию в оплату на лендинге и в интернет-магазине на Tilda. Штатных настроек хватает, пока доставка считается по фиксированной сумме или по порогу бесплатной отправки. Как только в дело идёт вес товара, регион покупателя или курьерская служба с разными тарифами по зонам, встроенных полей конструктора уже мало - нужен скрипт расчёта доставки для Tilda, который считает стоимость на лету и подставляет её в форму заказа до оплаты. Я такие скрипты делаю на заказ регулярно, и ниже разберу, как это устроено технически, какие варианты интеграции есть и во сколько это обходится.

Что Tilda умеет считать сама, а что нет

В настройках корзины Tilda (блоки Zero Block, Cart, оплата через T‑Bank, ЮKassa) есть три штатных сценария доставки: фиксированная стоимость, бесплатная доставка от суммы заказа и выбор способа доставки с ручным списком цен по регионам. Для интернет-магазина с небольшим ассортиментом и одним городом отгрузки этого достаточно - настраивается за 20-30 минут в панели без единой строчки кода.

Проблема начинается там, где стоимость зависит не от суммы заказа, а от физических параметров: вес, объём, хрупкость, количество мест. Конструктор не умеет складывать вес позиций в корзине и подставлять цену по формуле. Не умеет он и обращаться к внешним API - например, дёргать калькулятор СДЭК или Boxberry, чтобы показать актуальный тариф с учётом фактического адреса, а не усреднённую цифру по региону. И третье ограничение - Tilda не различает способ оплаты и способ доставки как связанные сущности: нельзя сделать так, чтобы при выборе самовывоза автоматически скрывалось поле адреса и обнулялась стоимость доставки, без дополнительного скрипта.

Когда без кастомного скрипта расчёта доставки не обойтись

На практике кастомный расчёт запрашивают в четырёх случаях. Первый - мебель, стройматериалы, бытовая техника, где цена доставки напрямую зависит от веса и габаритов, и продавец не готов закладывать в цену товара доставку самого тяжёлого заказа. Второй - магазины с отгрузкой в несколько городов и разными тарифами транспортных компаний по каждому. Третий - интеграция с реальным API СДЭК или Почты России, когда клиент вводит адрес, а скрипт возвращает не примерную, а точную стоимость по тарифной сетке на дату заказа. Четвёртый - B2B-магазины, где доставка считается по формуле «объём + расстояние + срочность», и от этого зависит итоговая сумма, которая уходит в оплату через эквайринг.

В последнем случае расчёт доставки - только часть задачи: результат обязан попасть в сумму платежа до того, как клиент нажмёт «Оплатить», иначе получится расхождение между витриной и чеком, а это уже вопрос к 54-ФЗ и онлайн-кассе. Если задача just началась и непонятно, с чего стартовать, проще посмотреть на готовые скрипты для Tilda - часть логики расчёта по весу или зонам там закрывается без разработки с нуля, а под конкретную интеграцию дорабатывается уже точечно.

Способы реализовать калькулятор доставки в Tilda

Вариантов на практике четыре, и они закрывают разные бюджеты и сроки.

Последний вариант - встроенные виджеты СДЭК и Boxberry, которые можно подключить как готовый iframe с выбором пункта выдачи на карте. Это быстро, но гибкости почти нет: нельзя добавить свою наценку, скрыть определённые способы доставки для конкретных товаров или объединить расчёт с промокодами. Для точечных доработок обычно хватает JS-калькулятора, который живёт прямо в коде страницы и не требует бэкенда.

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

Логика по весу и объёму

Скрипт слушает событие обновления корзины Tilda, суммирует вес позиций (в карточку товара вес добавляется через дополнительное поле в настройках товара или через атрибут в CSV-выгрузке), сравнивает результат с тарифной сеткой и выводит цифру в отдельный блок формы заказа. Тарифная сетка обычно хранится прямо в скрипте в виде объекта - для магазина с 3-5 зонами доставки этого достаточно, менять её потом можно без переразработки, просто отредактировав цифры.

Логика по зонам и городам

Если расчёт завязан на регион, добавляется выпадающий список городов или полей с автоподстановкой через DaData, и уже выбранное значение попадает в ту же функцию расчёта вместе с весом. Здесь важно не потерять пересчёт при изменении корзины - если покупатель убрал товар после выбора города, стоимость должна обновиться автоматически, а не остаться прежней.

Вот упрощённый пример логики - она показывает принцип, а не готовое решение под конкретный магазин:

function calcDelivery(weightKg, zone) {
  const rates = {
    msk: { base: 300, perKg: 40 },
    spb: { base: 350, perKg: 45 },
    regions: { base: 450, perKg: 60 }
  };
  const rate = rates[zone] || rates.regions;
  const cost = rate.base + Math.max(0, weightKg - 1) * rate.perKg;
  return Math.round(cost);
}

document.addEventListener('tcart:updated', function () {
  const cart = window.tcart || {};
  const totalWeight = (cart.products || []).reduce(function (sum, p) {
    return sum + (p.weight || 0.5) * p.quantity;
  }, 0);

  const zoneSelect = document.querySelector('[name="zone"]');
  const zone = zoneSelect ? zoneSelect.value : 'regions';
  const deliveryCost = calcDelivery(totalWeight, zone);

  const field = document.querySelector('#delivery-cost');
  if (field) field.textContent = deliveryCost + ' u20BD';
});

В реальном проекте сюда добавляются обработка ошибок (товар без указанного веса, не выбранный город), локальное кеширование последнего расчёта и синхронизация с полем итоговой суммы в форме оплаты - без этого сумма на экране и сумма в чеке могут разойтись.

Интеграция с оплатой и CRM после расчёта

Считать доставку отдельно от оплаты бессмысленно, если магазин принимает деньги онлайн. У T‑Bank и ЮKassa в конструкторе Tilda сумма платежа берётся из корзины, и если доставка не входит в неё программно, покупатель либо доплачивает отдельно (что снижает конверсию), либо продавец теряет разницу. Правильная связка - скрипт добавляет рассчитанную стоимость доставки в тело корзины как отдельную позицию перед отправкой формы, и уже обновлённая сумма уходит в эквайринг.

Второй слой - передача данных о доставке в CRM. Если заказы падают в amoCRM или Bitrix24 через штатный вебхук Tilda, стоимость и способ доставки нужно прокинуть отдельными полями, иначе менеджер увидит только сумму товаров и потом будет уточнять адрес и тариф вручную. Для интернет-магазинов с оплатой я обычно закладываю такую интеграцию сразу в комплексную доработку - отдельно считать доставку, отдельно донастраивать CRM почти всегда выходит дороже, чем сделать один раз целиком.

Типичные ошибки при подключении расчёта доставки

• Вес товара не заполнен в карточках - скрипт считает по дефолтному значению и завышает или занижает стоимость.
• Расчёт не пересчитывается при удалении товара из корзины - покупатель видит старую сумму.
• Скрипт конфликтует с другим кодом на странице (частая история, если на сайте уже стоит несколько сторонних доработок и виджетов через один и тот же T123 или T228 блок).
• Мобильная версия не протестирована отдельно - поле с расчётом съезжает или не триггерится на touch-событиях.
• Итоговая сумма в форме оплаты не совпадает с суммой на экране расчёта - это видно сразу и бьёт по доверию на последнем шаге перед оплатой.

Большая часть этих ошибок всплывает не на тестировании разработчиком, а через неделю-две после запуска, когда через магазин проходит трафик из разных городов и с разных устройств. Поэтому после подключения расчёта доставки я обычно прогоняю несколько тестовых заказов вручную с разными весами и городами - это быстрее, чем потом разбирать жалобы клиентов.

Частые вопросы

Можно ли настроить расчёт доставки на Tilda без программиста?

Если доставка фиксированная или зависит только от суммы заказа - да, это делается в панели конструктора за полчаса. Как только появляется зависимость от веса, объёма или реального тарифа транспортной компании, нужен JS-скрипт, потому что таких инструментов в самой Tilda нет.

Как рассчитать доставку по весу товара на Tilda?

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

Реально ли подключить к Tilda реальные тарифы СДЭК или Boxberry?

Да, через API транспортной компании - скрипт отправляет вес, габариты и адрес, получает тариф в ответ и подставляет его в форму заказа. Это уже не JS-калькулятор с фиксированной сеткой, а полноценная интеграция, поэтому и по срокам, и по стоимости она ближе к 40 000 ₽, а не к простой доработке за несколько тысяч.

Что делать, если расчёт доставки на сайте после подключения работает нестабильно?

Чаще всего причина в конфликте с другим скриптом на странице или в незаполненных данных о весе у части товаров. Стоит проверить консоль браузера на ошибки при обновлении корзины и прогнать несколько тестовых заказов с разными городами и весами - обычно проблема находится за 15-20 минут диагностики.