Кому нужны облачные кассы?

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

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

Да, арендуйте облачную кассу, если вам нужна готовая инфраструктура для онлайн-платежей без размещения оборудования у себя. До договора подтвердите состав тарифа: модель ККТ, ФН, ОФД, регистрацию, замену ФН, интеграцию и поддержку возвратов.

Что проверить перед подключением облачной кассы?

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

Нужна ли облачная касса при интернет-эквайринге?

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

Вернуться в Блог

Облачные кассы для бизнеса: выбор, подключение и запуск без лишних ошибок

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

Автор: Александр Пылев, Основатель Интернет Касса

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

Когда облачная касса нужна бизнесу

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

Интернет-магазин с оплатой на сайте

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

Сервис с подписками и регулярными списаниями

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

Продажи через менеджера

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

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

Отдельно разберите расчёты между организациями и ИП, агентские схемы и продажи через маркетплейсы. Здесь критичны способ расчёта, роль сторон и то, кто является продавцом в чеке. Официальные материалы о применении и регистрации ККТ доступны на сайте ФНС России.

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

Кому подходит аренда облачной кассы, а кому нужен другой контур

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

Небольшому интернет-магазину нужен модуль для CMS или готовая связка с эквайрингом, поиск чека по заказу и понятный маршрут возврата.
SaaS-сервису нужны API, вебхуки, тестовый контур, журнал ошибок и повторная безопасная обработка уведомлений.
Агентской модели нужно до старта определить продавца, состав реквизитов чека и сторону, которая отвечает за фискализацию. Не начинайте интеграцию, пока это не согласовано.

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

Таблица критериев выбора облачной кассы

Критерий	Интернет-магазин	Подписочный сервис	Что спросить поставщика
Платёжные сценарии	Оплата заказа, предоплата, доплата, возврат	Первое и повторное списание, отмена подписки, возврат	Какие события создают чек и как система исключает дубли?
Интеграция	Модуль CMS или связка с эквайрингом	API, вебхуки, тестовый контур	Есть ли документация, логи запросов и поддержка интеграции?
ККТ и регистрация	Модель из реестра ККТ, понятный порядок регистрации	То же, плюс доступ к настройкам нескольких проектов	Какая модель используется, включена ли она в реестр и кто выполняет регистрацию в ФНС?
ФН и ОФД	Контроль передачи чеков и сроков обслуживания	Очередь неотправленных чеков, выгрузка статусов	Что входит в услугу по ФН, кто и как организует его замену, какой ОФД подключён?
Реквизиты и ФФД	Корректные позиции, контакты и признаки расчёта	Передача данных по каждому списанию	Какие реквизиты и версии ФФД поддерживает интеграция?
Возвраты	Полный и частичный возврат по заказу	Возврат одного списания или части услуги	Какая система передаёт событие возврата и где виден итоговый статус?
Личный кабинет и поддержка	Поиск по номеру заказа и причина ошибки	Экспорт, фильтры, роли сотрудников	Как долго хранится история, какие уведомления есть и кто отвечает на инцидент?
Тариф	Прозрачный состав запуска	Понятные условия для объёма операций и поддержки	Что включено: ККТ, ФН, ОФД, регистрация, интеграция, замена ФН и поддержка?

Эквайринг и касса должны обмениваться статусами как единая цепочка. Вопросы к банку, агрегатору и технической команде собраны в материале «Интернет-эквайринг для сайта: выбор, подключение и запуск оплаты».

Как подключить облачную кассу: пошаговый запуск

Составьте реестр операций. Внесите успешную оплату, получение предоплаты, зачёт предоплаты, доплату, полный и частичный возврат. Для каждой операции укажите источник события: сайт, CRM, биллинг, менеджер или платёжный сервис.
Разведите три разных события. Отмена до успешной оплаты не создаёт расчёт и не должна запускать чек. Возврат после принятой оплаты требует отдельного процесса возврата. Ошибочно сформированный чек исправляйте отдельной процедурой, а не повторной продажей.
Проверьте контур ККТ. Убедитесь, что модель ККТ есть в реестре, согласован порядок регистрации в ФНС и понятен состав услуги по ФН, ОФД и замене ФН.
Настройте передачу данных. Свяжите сайт или CRM, эквайринг, кассу и ОФД идентификатором заказа. Передавайте сумму, позиции, признаки предмета и способа расчёта, ставку налога при её применении, а также email или телефон покупателя.
Проведите тесты до продаж. Проверьте успешную оплату, предоплату с последующим зачётом, доплату, повторное уведомление от платёжного сервиса, полный и частичный возврат. В каждом тесте должны совпасть заказ, платёж, чек и его статус.
Назначьте владельцев процесса. IT разбирает ошибки интеграции, бухгалтерия контролирует фискальные документы, а сотрудники продаж знают маршрут возврата. Закрепите сотрудника, который регулярно проверяет неотправленные чеки и очередь ошибок.

Ошибки при запуске облачной кассы

Отмену путают с возвратом. Не формируйте возврат, если платёж не состоялся. Если деньги уже приняты, запускайте процесс возврата; если чек сформирован ошибочно, применяйте отдельный порядок исправления.
Предоплату оформляют как полный расчёт. Настройте разные события для получения предоплаты и её зачёта, когда продажа проходит в два этапа.
Платёж не связан с заказом. Передавайте единый идентификатор заказа через CMS или CRM, эквайринг и кассу.
Не тестируют дубли и возвраты. Повторное уведомление от платёжного сервиса не должно создавать второй чек. Полный и частичный возврат проверьте до выхода в продакшен.
Игнорируют статусы ОФД. Настройте уведомления и регламент контроля. Чек, сформированный в кассовом сервисе, и чек со статусом успешной передачи — разные точки проверки.
Выбирают тариф без проверки состава. Сначала подтвердите модель ККТ, регистрацию, ФН, ОФД, поддержку реквизитов, API и логи; затем сравнивайте цену.

Что проверить до оплаты договора и запуска

Модель ККТ включена в реестр, а порядок её регистрации в ФНС согласован письменно.
В договоре перечислены ККТ, ФН, ОФД, регистрационные действия, замена ФН, интеграция, техническая поддержка и ответственность сторон.
Поставщик подтвердил поддержку нужных реквизитов и используемой версии формата фискальных документов.
Личный кабинет позволяет найти чек по номеру заказа, увидеть его статус и причину ошибки, выгрузить историю операций.
Доступы разделены между бухгалтерией, IT и руководителем; учётная запись не привязана к личной почте одного сотрудника.
Команда проверила успешную оплату, предоплату с зачётом, доплату, полный и частичный возврат, повторное уведомление и сценарий ошибочного чека.
Для маркированных товаров, агентской схемы, подписок и подарочных сертификатов согласованы отдельные правила до старта продаж.

Вывод: выбирайте облачную кассу после карты платежей и тестового сценария, а не по названию тарифа. Провайдер должен подтвердить не только подключение оплаты, но и работу ККТ, ФН, ОФД, возвратов, реквизитов чека и нужной интеграции.

Нужна рабочая схема до подключения? Свяжитесь с командой Интернет Касса. Разберём платёжный путь, определим сценарии чеков, проверим состав услуги и подскажем следующий шаг для запуска.