Онлайн-касса в Битрикс: 7 ошибок новичков

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

Что подготовить до настройки

Примеры ниже рассчитаны на 1С-Битрикс: Управление сайтом 24.x. В более новых и старых версиях названия пунктов могут отличаться, особенно если используется готовый модуль платёжного провайдера.

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

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

Оплата и фискализация — разные события. Успешный платёж ещё не доказывает, что чек создан, зарегистрирован и отправлен покупателю.

Подключение по шагам

1. Выберите одну платёжную схему. В кабинете провайдера проверьте, кто создаёт чек: сам сервис или интернет-магазин. Если чек формирует провайдер, в Битрикс обычно передают позиции заказа и параметры налогообложения. Если чек формирует сайт, нужен отдельный обработчик или модуль, который отправляет данные на кассу.
   Проверка: в документации и настройках провайдера явно указано одно место формирования чека, а не два параллельных сценария.
2. Создайте или подключите платёжную систему. В административной части откройте раздел настроек интернет-магазина, найдите платёжные системы и добавьте обработчик вашего провайдера. Выберите рабочий сайт, валюту и способы оплаты. Не включайте боевой режим, пока тестовый платёж не проходит полностью.
   Проверка: платёжная система отображается в заказе, активна для нужного сайта и не подставляется в другой интернет-магазин из той же установки.
3. Заполните идентификаторы провайдера. Обычно это идентификатор магазина, секретный ключ или пара параметров для API. Копируйте значения из кабинета провайдера без пробелов и переносов. Секретный ключ храните только в настройках сервера или модуля, не вставляйте его в шаблон и JavaScript.
   Проверка: сохранение настроек проходит без ошибки авторизации, а тестовый запрос в кабинете провайдера не возвращает статус «неверные учётные данные».
4. Настройте состав чека. Передавайте в чек название товара, количество, цену, ставку налога и тип расчёта. Проверьте, как система обрабатывает доставку, скидку, подарочный сертификат и частичный возврат. Название товара должно быть понятным покупателю, а не только внутренним кодом из каталога.
   Проверка: в тестовом чеке есть все позиции заказа, итоговая сумма совпадает с оплатой, а доставка не исчезла из фискального документа.
5. Сопоставьте статусы заказа. Оплата может получить статус «успешно» у провайдера, но остаться в Битрикс в состоянии «принят» или «ожидает оплаты». Провайдер должен отправить уведомление на доступный извне адрес, а сайт — проверить подпись этого уведомления и изменить статус заказа.
   Проверка: после тестовой оплаты заказ автоматически меняет статус, а в журнале провайдера есть успешная доставка уведомления на ваш домен.
6. Проверьте возврат и отмену. Отдельно протестируйте полный и частичный возврат. Для них может формироваться чек коррекции или чек возврата, а состав документа не всегда совпадает с первоначальным заказом. Правило зависит от схемы провайдера и настроек кассы.
   Проверка: в кабинете провайдера появляется документ возврата с правильной суммой, а заказ в Битрикс получает соответствующий статус.
7. Переключите боевой режим и повторите контроль. Перед включением реальных платежей сохраните тестовые настройки, проверьте домен, сертификат, часовой пояс и адрес уведомлений. Сделайте небольшой реальный платёж только после того, как тестовый чек и тестовый возврат завершились без ошибок.
   Проверка: у боевого заказа есть номер платежа, номер фискального документа и ссылка на чек, а данные видны в кабинете кассы или оператора фискальных данных.

Семь ошибок, из-за которых чек не появляется

1. Проверяют только страницу оплаты

Редирект на страницу «Платёж выполнен» не означает, что Битрикс получил серверное уведомление. Пользователь мог закрыть вкладку, а платёжный провайдер — не достучаться до сайта. Проверяйте заказ в административной части, журнал платёжного модуля и кабинет провайдера.

2. Указывают неправильный адрес уведомлений

Частые причины — тестовый домен, закрытый Basic Auth, запрет запросов по IP, неверный SSL-сертификат или редирект с HTTPS на HTTP. Провайдер должен обращаться к публичному адресу, который отвечает без авторизации и не требует действий в браузере.

3. Не передают позиции заказа

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

4. Ставка налога задана текстом из каталога

В карточке товара может быть написано «без НДС», «20%» или произвольное внутреннее значение, а API провайдера ждёт конкретный код или допустимое название. Сопоставление нужно делать в настройках модуля, а не надеяться на автоматическое распознавание произвольного текста.

5. Доставка не считается товарной позицией

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

6. Секретный ключ заменили на публичный

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

7. Тестовый режим оставили включённым

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

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

Если не получилось: быстрый разбор

• «Invalid credentials», «unauthorized» или «неверные данные доступа». Проверьте идентификатор магазина, секретный ключ, режим test/live и лишние пробелы. После смены ключа сохраните настройки и повторите новый платёж, а не старый.
• «Не удалось создать чек» или «ошибка передачи позиций». Сравните состав заказа с требованиями провайдера: количество, цена, ставка налога, тип расчёта и данные покупателя. Уберите из теста сертификат, бонусы и сложную скидку, затем добавляйте их по одному.
• Платёж успешен, но заказ не меняет статус. Проверьте доступность адреса уведомлений, SSL-сертификат и записи журнала. Если провайдер показывает повторные попытки, проблема обычно на пути к сайту или в проверке подписи.
• Чек создан дважды. Оставьте только один механизм фискализации. Проверьте, не включены ли одновременно встроенная касса Битрикс и чек в платёжном модуле.
• Сумма в чеке отличается от заказа. Ищите расхождение в округлении, скидке, доставке или валюте. Сравнивайте не только итоговую сумму, но и каждую строку перед отправкой.

Что проверить перед публикацией магазина

Сделайте короткий прогон на отдельном тестовом товаре: новая оплата, повторное открытие заказа, полный возврат, частичный возврат и письмо со ссылкой на чек. После этого посмотрите журналы Битрикс и провайдера за один и тот же период. Если там разные часовые пояса, события будет трудно сопоставить.

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

¹ В разных модулях этот механизм может называться callback, notification или URL уведомлений. Название меняется, смысл тот же: сервер провайдера сообщает сайту результат операции.