Интеграция кассы с Тильдой: как настроить фискализацию оплат

Когда клиент оплачивает заказ на сайте, магазин обязан выбить фискальный чек по 54-ФЗ, и для сайтов на Тильде это не всегда решается по умолчанию: интеграция кассы с Тильдой нужна ровно тогда, когда встроенных платёжных блоков конструктора недостаточно для схемы продаж клиента. На практике сталкиваюсь с этим на проектах, где кроме приёма карт на сайте есть оплата по счёту, самовывоз с оплатой при получении или продажи через маркетплейсы, которые Тильда фискализировать сама не умеет.

Зачем фискализировать оплаты на Тильде по 54-ФЗ

По закону 54-ФЗ каждая оплата товара или услуги физлицу должна сопровождаться кассовым чеком, который через оператора фискальных данных попадает в налоговую. Не важно, платит покупатель картой на сайте, переводом по ссылке или наличными курьеру, чек обязателен в любом случае. Штраф для ИП за отсутствие чека начинается от 25% суммы расчёта, но не менее 10 000 ₽, для компаний суммы выше. Тильда сама кассой не является: она либо интегрирована с платёжной системой, которая уже включает фискализацию, либо передаёт данные о заказе куда-то ещё, и вот это «куда-то ещё» настраивается отдельно.

Проблема в том, что владельцы сайтов часто ставят платёжный блок на Тильде, видят, что деньги приходят на счёт, и на этом успокаиваются. Чек при этом либо не формируется вообще, либо формируется с задержкой, либо не той кассой, которая зарегистрирована на юрлицо. Разбираться в этом лучше на этапе настройки сайта, а не после первой проверки от ОФД.

Встроенная фискализация в платёжных системах Тильды

У Тильды есть штатная интеграция с несколькими платёжными системами: Т‑Касса (бывшая Тинькофф Касса), ЮKassa, CloudPayments, Robokassa и Сбербанк Эквайринг. Все они уже включают в себя фискализацию: при оплате картой система сама формирует чек и отправляет его через своего ОФД. Для владельца сайта это самый простой путь, потому что кассовый аппарат физически регистрировать не нужно, всё уже привязано к договору с платёжной системой.

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

Когда нужна отдельная облачная касса для интеграции с Тильдой

Отдельную кассу подключают в трёх случаях: когда бизнес уже работает с конкретным ОФД и менять его не хочет, когда часть оплат идёт мимо встроенных платёжных блоков Тильды (по счёту, наличными, через сторонний сервис), и когда нужно фискализировать не только оплату, но и, например, предоплату с последующим зачётом. Здесь на помощь приходят облачные кассы: АТОЛ Онлайн, Orange Data, CloudKassir, Оrange Касса и подобные сервисы, которые сдают в аренду виртуальный или физический кассовый аппарат и принимают чеки через API.

Схема простая на бумаге: Тильда при оплате или смене статуса заказа отправляет вебхук на промежуточный сервер, сервер формирует запрос к API кассы с данными о товаре, сумме и способе оплаты, касса пробивает чек и возвращает ссылку на него, которую можно показать клиенту или отправить на почту. Сложность в деталях: Тильда по умолчанию не умеет вызывать произвольный API кассы, поэтому между ними всегда стоит прослойка кода.

Техническая схема: вебхук Тильды и API кассы

В настройках Тильды в разделе интернет-магазина или CRM-форм есть поле для вебхука, куда конструктор отправляет POST-запрос при каждом новом заказе или оплате. На стороне сервера этот запрос принимает небольшой скрипт, который проверяет статус оплаты, достаёт из тела запроса сумму, товары и контакты клиента, и уже от себя обращается к API выбранной кассы.

app.post('/tilda-webhook', async (req, res) => {
  const order = req.body;

  if (order.payment.status !== 'paid') {
    return res.sendStatus(200);
  }

  const receipt = {
    email: order.email,
    sum: order.payment.amount,
    items: order.products.map(p => ({
      name: p.name,
      price: p.price,
      quantity: p.quantity,
      tax: 'vat22'
    }))
  };

  await fetch('https://kassa-provider.example/api/v2/receipts', {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${process.env.KASSA_TOKEN}` },
    body: JSON.stringify(receipt)
  });

  res.sendStatus(200);
});

Важный нюанс, о который спотыкается большинство самостоятельных настроек: Тильда может присылать вебхук несколько раз для одного заказа, например при создании заказа и при смене статуса на «оплачен». Если не проверять, был ли уже пробит чек по этому номеру заказа, касса задвоит чеки, и в отчётах ОФД появится расхождение с реальной выручкой. Для таких доработок обычно делаю кастомный скрипт интеграции, который хранит статусы заказов в своей базе и исключает повторную фискализацию одной и той же оплаты.

Сравнение способов фискализации оплат на Тильде

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

Частые ошибки при настройке связки кассы и Тильды

Чаще всего вижу три повторяющиеся проблемы. Первая, чек уходит на кассу, зарегистрированную не на то юрлицо, которое указано в оферте на сайте, обычно это остаётся с этапа, когда сайт делала одна команда, а кассу подключал бухгалтер отдельно. Вторая, вебхук Тильды настроен на тестовый адрес сервера и после переезда на боевой домен забывают его переключить, чек просто перестаёт формироваться и никто не замечает, пока не приходит запрос от налоговой. Третья, товары с разными ставками НДС (например часть с 22%, часть без НДС при УСН) в чеке передаются одной строкой с общей ставкой, что при проверке всплывает как нарушение.

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

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

Можно ли использовать одну кассу для нескольких сайтов на Тильде?

Можно, если все сайты принадлежат одному юрлицу или ИП и продают через один расчётный счёт. В вебхуке каждого сайта просто указывается один и тот же токен кассы, а в теле чека передаётся название точки продаж, чтобы в отчётах ОФД было видно, откуда пришёл заказ.

Что будет, если оплата на сайте прошла, а чек не сформировался?

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

Как быть с оплатой по счёту или при личной встрече, если сайт на Тильде?

Встроенные платёжные блоки Тильды такие оплаты не видят, потому что деньги проходят мимо сайта. Здесь нужна ручная или полуавтоматическая передача данных на кассу: либо менеджер вносит оплату в отдельном интерфейсе кассы, либо CRM, куда падают заказы с Тильды, сама дергает API кассы при смене статуса на «оплачено».

Сколько времени занимает подключение кассы к Тильде?

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