Webkassa и Regos, фискальные чеки при онлайн-оплате

Фискальный чек при онлайн-оплате пробивается не банком, а отдельным сервисом: после того как платёж подтверждён, ваша система передаёт в Webkassa (Казахстан) или Regos (Узбекистан) данные о продаже и получает фискальный документ, ссылку на который отдаёт покупателю. Главное, что нужно продумать заранее, это момент пробития чека, содержимое позиций и что делать, если сервис ответил ошибкой. Точные методы и поля берите из документации провайдера, ниже я описываю общую логику.

Откуда берётся чек при интернет-оплате

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

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

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

Когда пробивать чек, до оплаты или после

Здесь возможны разные схемы, и выбор зависит от вида расчётов и требований вашей отрасли.

Самая частая схема для онлайн-продаж: чек формируется после подтверждения платежа. Последовательность такая:

1. Покупатель оформляет заказ, заказ получает статус «ожидает оплаты».
2. Платёжная система присылает подтверждение об успешной оплате (уведомление на ваш адрес или ответ при возврате на сайт).
3. Вы проверяете подлинность уведомления и сумму, переводите заказ в статус «оплачен».
4. Ставите задачу на фискализацию: отправляете данные в кассовый сервис.
5. Получаете чек, сохраняете его номер и ссылку, отправляете покупателю.

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

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

Какие данные нужны для фискального чека

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

• идентификация кассы или точки продаж, под которой пробивается чек (она настраивается в кабинете сервиса);
• список позиций: наименование, количество, цена, сумма, иногда единица измерения и признак налога;
• способ оплаты: безналичный, наличный, смешанный, с указанием сумм;
• тип операции: продажа, возврат продажи;
• контакт покупателя (email или телефон), если чек нужно отправить электронно;
• информация о налогообложении, зависящая от вашего режима и настроек сервиса;
• внутренний идентификатор операции, который вы генерируете сами.

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

Суммы позиций должны сходиться с оплаченной суммой копейка в копейку, включая доставку и скидки. Расхождение из-за округления НДС или процента скидки — одна из самых частых причин отказа в пробитии. Ведите расчёт в минимальных единицах или с фиксированным правилом округления и всегда сверяйте итог с суммой платежа до отправки.

Что делать при ошибках и повторных попытках

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

Сервис временно недоступен или вернул ошибку сервера. Задача остаётся в очереди и повторяется с нарастающей паузой. После нескольких неудач она помечается как требующая внимания, и ответственный получает уведомление.

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

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

Смена кассовой смены или лимиты. У некоторых сервисов есть понятие смены с ограничениями по времени. Правила разные, их надо читать в документации, а вашей системе стоит уметь корректно реагировать на сообщение «смена закрыта» или похожее.

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

Возвраты и отмены

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

Технически возврат должен быть связан в вашей системе с исходным заказом и исходным чеком. Для частичных возвратов отдельно храните, какие позиции и в каком количестве возвращены, чтобы сумма не превысила оплаченную. Хорошая практика: возврат платежа в банке и возврат чека делаются как две связанные задачи с собственными статусами, и расхождение между ними видно в отчёте.

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

Что проверить перед запуском

Мой контрольный список для кассовой части интеграции:

1. Тестовая среда или тестовая касса прошла сценарии: обычная продажа, продажа нескольких позиций, со скидкой, с доставкой.
2. Проверены возвраты: полный и частичный.
3. Проверено поведение при недоступности сервиса: задача не теряется и повторяется.
4. Двойная отправка одного и того же заказа не создаёт двух чеков.
5. Чек и ссылка на него сохраняются в заказе и доступны менеджеру.
6. Покупатель получает чек на указанный контакт, а неверный контакт не блокирует заказ.
7. Суммы позиций совпадают с суммой платежа во всех проверочных сценариях.
8. Настроено уведомление ответственного о задачах, застрявших в ошибке.
9. Параметры доступа к сервису хранятся вне кода, а не в репозитории.

Более общий перечень проверок платёжной части есть в материале о тестировании платёжной интеграции.

Как хранить данные о чеках и что показывать менеджеру

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

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

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

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

Компании, которые работают в обеих странах, нередко пытаются сделать единый модуль и потом сталкиваются с различиями. Различаются форматы данных, названия полей, правила налогов, процедуры регистрации кассы, а также привычные платёжные сервисы: в Казахстане это банковский эквайринг и Kaspi, в Узбекистане чаще Payme и Click. Поэтому разумнее строить собственный слой: внутри системы вы работаете с единой моделью «продажа, позиции, оплата, возврат», а для каждой страны есть отдельный адаптер, который переводит эту модель в запросы конкретного сервиса. Тогда замена провайдера или добавление нового рынка не затрагивает остальную систему. Подробнее о местной специфике платежей смотрите в статье про Payme и Click для сайта в Узбекистане.

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

Нужно ли пробивать чек на каждую онлайн-оплату?

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

Чем отличаются Webkassa и Regos?

Это разные сервисы для разных стран: Webkassa используется в Казахстане, Regos в Узбекистане. У них различаются форматы запросов, настройки и местные требования, поэтому код под один не подойдёт для другого без доработки. Подробности смотрите в документации каждого провайдера.

Что, если покупатель не указал email?

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

Можно ли пробивать чек вручную из кабинета?

Для небольшого числа заказов можно, но при росте объёма это приведёт к опозданиям и ошибкам. Автоматизация экономит время и уменьшает человеческий фактор.

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