54-ФЗ и онлайн-чек при оплате на сайте — publi.ru

54-ФЗ и онлайн-чек при оплате на сайте

7 мин чтения · чек-лист · тем, кто заказывает · обновлено 2026-09-02

Если сайт принимает оплату от физических лиц, покупателю в общем случае направляется кассовый чек. Формирует его кассовый сервис, а сайт передаёт в него состав заказа. Настоящая справка описывает, что именно передаётся, кто за что отвечает и в каком порядке это проверяется до запуска.

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

1. Участники и зоны ответственности

Участник За что отвечает
Сайт Хранение состава заказа, инициирование чека, передача данных
Платёжный провайдер Проведение платежа, уведомление сайта о результате
Кассовый сервис Формирование фискального документа
Оператор фискальных данных Передача сведений в налоговую
Бухгалтер владельца Налоговый режим, ставки, признаки расчёта, применимость требований
Владелец бизнеса Договоры с кассовым сервисом и эквайером, оплата сервисов

Разработчик работает только с первой строкой таблицы и её стыком со второй и третьей.

2. Состав данных, передаваемых сайтом

2.1. Наименование каждой позиции заказа.

2.2. Количество по каждой позиции.

2.3. Цена единицы по каждой позиции.

2.4. Ставка налога по каждой позиции.

2.5. Признак способа расчёта — полная оплата, предоплата, аванс.

2.6. Признак предмета расчёта — товар, услуга, работа.

2.7. Итоговая сумма заказа.

2.8. Контакт покупателя для направления чека — адрес электронной почты либо номер телефона.

2.9. Стоимость доставки отдельной позицией, если доставка платная.

Значения пунктов 2.4, 2.5 и 2.6 задаёт бухгалтер владельца. Разработчик обеспечивает их корректную передачу, но не выбирает.

3. Требования к данным на стороне сайта

3.1. Состав заказа хранится позициями. Хранение одной строкой вида «Заказ №1234» на общую сумму не допускается.

3.2. Ставка налога хранится в свойствах товара, а не задаётся общим значением для всего каталога, если в каталоге есть позиции с разными ставками.

3.3. Скидка раскладывается по позициям. Скидка, применённая общей суммой к заказу, приводится к позиционному виду перед передачей.

3.4. Контакт покупателя для чека является обязательным полем оформления заказа.

3.5. Чек инициируется по факту подтверждённого платежа, а не по факту возврата покупателя на страницу подтверждения.

Пункт 3.5 повторяет общее правило работы с оплатой: статус заказа и фискализация запускаются уведомлением от провайдера.

4. Порядок подключения

4.1. Владелец заключает договор с кассовым сервисом и получает доступы.

4.2. Владелец совместно с бухгалтером определяет ставки, признаки расчёта и предмета расчёта для каталога.

4.3. Разработчик подключает сайт к кассовому сервису в тестовом режиме.

4.4. Проводятся тестовые операции по пункту 5.

4.5. Подключение переводится в рабочий режим.

4.6. Доступы кассового кабинета остаются у владельца.

5. Перечень проверок до запуска

Каждая проверка выполняется как реальная операция, а не как осмотр настроек.

5.1. Заказ из одной позиции. Чек получен, наименование и цена совпадают с сайтом.

5.2. Заказ из нескольких позиций с разным количеством. В чеке все позиции, суммы сходятся.

5.3. Заказ с позициями разных налоговых ставок, если такие в каталоге есть.

5.4. Заказ со скидкой. Скидка отражена по позициям, итог совпадает со списанной суммой.

5.5. Заказ с платной доставкой. Доставка отдельной позицией.

5.6. Заказ, оплаченный по СБП, и заказ, оплаченный картой. Чек формируется в обоих случаях.

5.7. Отменённый платёж. Чек не формируется.

5.8. Возврат средств. Оформлен по правилам кассового сервиса.

5.9. Чек получен на почту и на телефон — в зависимости от того, какие контакты вы принимаете.

Результаты проверок фиксируются письменно и прикладываются к акту приёмки.

6. Типовые расхождения, выявляемые на проверках

6.1. Скидка передана одной суммой — итог чека не совпадает с суммой позиций.

6.2. Ставка налога задана единой для каталога, в котором есть позиции с разными ставками.

6.3. Доставка включена в цену последней позиции вместо отдельной строки.

6.4. Наименование позиции в чеке отличается от наименования на сайте — например, содержит внутренний артикул.

6.5. Чек формируется дважды при повторной отправке уведомления провайдером.

Расхождение 6.5 устраняется защитой от повторной обработки: одно уведомление по одному платежу порождает один чек.

7. Что не входит в работу разработчика

7.1. Выбор кассового сервиса и оператора фискальных данных.

7.2. Заключение договоров и оплата сервисов.

7.3. Определение обязанности применять кассу.

7.4. Определение налоговых ставок и признаков расчёта.

7.5. Корректировка ранее сформированных фискальных документов.

7.6. Бухгалтерская отчётность и сверка.

8. Когда фискализация на сайте не требуется

8.1. Оплата принимается вне сайта — по счёту при работе с юридическими лицами.

8.2. Сайт не принимает оплату и служит для приёма заявок.

8.3. Расчёт производится очно при получении.

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

9. Что фиксируется при приёмке

9.1. Наименование кассового сервиса и оператора фискальных данных.

9.2. Подтверждение, что доступы к кассовому кабинету находятся у владельца.

9.3. Результаты проверок по пункту 5 с указанием даты проведения.

9.4. Перечень товарных групп с указанием ставки налога, согласованный с бухгалтером.

9.5. Порядок действий при расхождении: к кому обращаться и в какой срок.

Пункт 9.5 избавляет от типовой ситуации, когда чек ушёл неверный, а стороны выясняют, чья это зона.

10. Эксплуатация после запуска

10.1. Изменение ассортимента. При добавлении товарной группы с иной ставкой налога ставка задаётся до появления товара в продаже.

10.2. Изменение налогового режима. Настройки кассового сервиса обновляются владельцем; передача данных с сайта изменений не требует, если состав чека остался прежним.

10.3. Смена кассового сервиса. Выполняется как отдельная работа: подключение к новому сервису и повторное проведение проверок по пункту 5.

10.4. Изменение требований внешних сервисов. Работы по приведению интеграции в соответствие относятся к дополнительным и в гарантию не входят.

Пункт 10.4 указан явно, поскольку его часто относят к гарантийным случаям. Гарантия покрывает ошибки исполнителя, а не изменения на стороне третьих лиц.

Коротко

Сайт не формирует чек, а передаёт в кассовый сервис состав заказа: позиции, количество, цены, ставки и признаки расчёта. Отсюда требование к данным — заказ хранится позициями, ставка живёт в свойстве товара, скидка раскладывается по строкам, доставка идёт отдельной позицией. Чек запускается уведомлением от платёжного провайдера и только один раз на платёж. Перед запуском выполняется девять тестовых операций, результаты фиксируются письменно; выбор сервисов, договоры и налоговые решения остаются за владельцем и его бухгалтером.

Расскажите, что нужно — посмотрим и скажем честно

Первый разговор — разбор задачи: нужна ли вам система или хватит одной страницы. Без обязательств и без счёта.

или оставьте номер — перезвоним

Перезваниваем в рабочее время. Ничего не рассылаем.

Оператор персональных данных — ИП Постнов Артём Сергеевич, ИНН 772610459593.

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

Заменяет ли эта справка консультацию бухгалтера?

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

Что произойдёт, если чек уйдёт с неправильным составом?

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

Кто оплачивает кассовый сервис?

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

Помогла статья?

Те, что не помогают, мы переписываем — по этой кнопке и решаем, какие именно.

Ещё по теме