- «Нам нужна онлайн-касса. Лучше сразу универсальная».
- «Где клиент платит: на сайте, по ссылке, в мессенджере, в точке?»
- «Пока везде понемногу. SberPay еще хотим. С чеками потом разберемся».
После этой фразы проект обычно начинает дорожать. Люди выбирают кассу, хотя на самом деле нужно собирать весь путь денег: оплата, чек, возврат, статус заказа, уведомление клиенту. Если этот маршрут не собран целиком, платеж проходит, а чек нет. Дальше появляются Excel, ночные выгрузки и раздраженный бухгалтер.
Выбирать надо маршрут денег и чеков
Интернет-эквайринг и онлайн-касса - это разные части процесса. Банк принимает деньги. Касса по 54-ФЗ формирует чек и отправляет его через оператора фискальных данных. SberPay, QR, карта, платежная ссылка - это способ принять оплату, но не способ выдать чек.
В работе схема почти всегда одна: клиент платит, банк подтверждает платеж, событие уходит в кассовый контур, касса пробивает чек, чек отправляется по email или SMS. Платеж прошел еще не означает, что чек отправлен.
У нас был интернет-магазин на WooCommerce с CloudPayments и облачной кассой. Эквайринг подключили быстро, а webhook на кассу не включили. Деньги поступали 14 дней, чеков не было вообще. Потом мы вручную собирали заказы, поднимали очередь в Redis и закрывали хвосты ночью.
Эквайринг уже подключен. Значит, вопрос закрыт?
Нет. Во многих проектах это отдельный контур, и ломается все как раз на стыке между банком и кассой.
SberPay решает фискализацию?
Тоже нет. Это еще один канал оплаты внутри той же схемы.
Для онлайна обычно нужна облачная касса, для точки - отдельный контур
Если бизнес продает только онлайн - услуги, доступы, заявки по ссылке, оплаты через Telegram или CRM, - я почти всегда рекомендую облачную кассу. Физическое устройство на столе в такой схеме только мешает. Ручной работы больше, странных сбоев тоже, пользы - ноль.
Если есть самовывоз, администратор, курьер с оплатой на месте или розничная точка, нужна физическая касса или смарт-касса вроде Эвотор. Смешивать все в один контур обычно неудобно: возвраты начинают жить отдельно, чеки путаются, сверка занимает лишнее время.
| Сценарий | Что ставить | Что проверить |
|---|---|---|
| ИП, услуги онлайн | платежная ссылка + облачная касса | чек уходит сразу после оплаты |
| Интернет-магазин | эквайринг + облачная касса + модуль CMS | статусы заказа и возвраты |
| Точка + сайт | касса в точке + отдельный онлайн-контур | чеки не смешиваются |
| SaaS/подписка | API, рекурренты, автофискализация | токены, отмены, частичные списания |
На проекте для салона услуг сначала хотели одну кассу на все: предоплата на сайте, доплата в салоне, сертификаты через WhatsApp. Мы тоже сначала пошли в эту сторону, и это была ошибка. Возвраты путались, администратор видел не те оплаты, бухгалтеру приходилось перепроверять все вручную. В итоге разделили контуры: онлайн-предоплаты ушли в облачную кассу, точка осталась на своей. Запуск занял 4 недели, число ошибок в обращениях снизилось примерно на 37%.
Банк лучше выбирать по объему ручной работы после запуска
Комиссия сама по себе почти ничего не говорит. Разница в 0,3% красиво выглядит в договоре, но один банк дает готовый модуль для CMS, webhooks и частичные возвраты, а второй присылает PDF с API и пожелание интегрировать все самостоятельно. На практике такая экономия сгорает быстро.
Я обычно проверяю пять вещей:
- комиссию и срок вывода денег
- качество API и документации
- возвраты и частичные возвраты
- готовые модули для CMS или CRM
- поддержку в дни запуска
Если вам нужны SberPay, холдирование, split-платежи или рекурренты, это стоит выяснять до подписания договора. У нас был B2B-сервис, где провайдера выбрали по знакомству. Потом выяснилось, что нужного сценария возврата нет, а страница оплаты уже утверждена. Переделка стоила 2 недели и около 180 000 ₽.
Хороший эквайринг - это когда после запуска менеджер и бухгалтер почти не трогают оплату руками.
Кнопка оплаты подключается быстро, автоматизация требует нормальной логики событий
Когда есть свой бэкенд, вопрос быстро уходит дальше формы оплаты. Нужно связать успешный платеж, чек, уведомление клиенту, возврат, сверку статусов. Если этого нет, в системе появляются дубли, потерянные статусы и споры с клиентами.
На B2C-сервисе на Node.js 20 + NestJS и PostgreSQL 16 мы переводили чеки с ручной отправки на API-интеграцию. События шли через очередь задач, каждый платеж получал свой идентификатор, повторные запросы не создавали второй чек. После запуска обращений «я оплатил, где чек?» стало меньше на 42%.
Было:
- менеджер отправляет ссылку вручную
- бухгалтер отдельно сверяет оплату
- чек может уйти с задержкой до суток
Стало:
- платеж меняет статус заказа
- касса отправляет чек автоматически
- возврат идет по тому же order_id
payment succeeded
-> create receipt
-> save fiscal status
-> send event to CRM
-> wait refund event
-> reconcile statuses
Ошибаются обычно не в кассе, а в модели оплаты
Услугам и B2B часто хватает ссылки на оплату, CRM и облачной кассы. Им не нужен тяжелый магазин со своей корзиной. Зато e-commerce без автоматических возвратов, доставки и статусов начинает трещать уже на первых десятках заказов в день.
С подписками другая история. Там нужны токенизация, рекуррентные списания и чек по событию, а не по утренней выгрузке. Мы один раз оставили фискализацию «на стороне бухгалтерии» для цифрового сервиса, потому что на старте это казалось быстрее. Через месяц, когда выросло число оплат, схема перестала справляться, и контур пришлось переписывать уже под нагрузкой. Это всегда дороже, чем сделать нормально сразу.
В ближайшие 3 дня я бы не выбирал модель кассы по каталогу. Я бы нарисовал на одном листе все точки оплаты - сайт, ссылка, мессенджер, офлайн, подписка - и для каждой ответил на один вопрос: кто и в какой момент отправляет чек. Если на любом шаге ответ звучит как «потом руками», у вас еще нет платежной системы. У вас есть будущая проблема.
