Интеграция онлайн-кассы для сайта нужна, чтобы после оплаты покупателя данные заказа без ручного ввода дошли до кассы, затем в ОФД и учет. Рабочая схема для интернет-магазина или сервиса выглядит так: сайт → эквайринг → backend → ККТ → ОФД → 1С.
После этой статьи вы сможете выбрать между CMS-модулем, прямой API-интеграцией и связкой с 1С, определить момент создания чека и составить тестовый план без лишних чеков и расхождений.
Подключайте автоматическую фискализацию, если принимаете оплату картой на сайте, по платежной ссылке или по подписке. Ручное оформление чеков после онлайн-платежей приводит к трем проблемам: сотрудник пропускает оплату, переносит неверную сумму или не оформляет частичный возврат.
До разработки составьте карту расчетов. Для каждого события укажите источник данных, момент создания чека, состав позиций и ответственного: успешная оплата, предоплата, отгрузка, оказание услуги, доплата, отмена до списания, полный и частичный возврат.
Не создавайте чек при нажатии кнопки «Оплатить» и при создании заказа. Эти события не подтверждают поступление денег. Сначала платежный контур должен подтвердить операцию, а backend — проверить это подтверждение.
CMS или frontend формирует заказ. Платежный сервис принимает оплату и отправляет уведомление о результате. Backend проверяет уведомление, берет состав заказа, передает данные в кассу и сохраняет результат фискализации. ККТ направляет сведения в ОФД, а 1С получает данные для учета оплат, реализаций и возвратов.
Не принимайте webhook на веру. Backend должен проверить подпись или секрет уведомления по правилам платежного провайдера, сверить идентификатор платежа и заказа, сумму, валюту и разрешенный финальный статус. Если провайдер предусматривает запрос статуса через API, используйте его для спорных или повторно полученных уведомлений.
Защитите контур от дублей. Сохраняйте идентификатор платежа, идентификатор заказа, ключ операции фискализации и номер сформированного чека. При повторной доставке того же webhook система должна вернуть результат уже обработанной операции, а не отправить второй запрос в кассу.
Статус «оплачено» в заказе меняйте после надежной проверки платежа. Статус «чек сформирован» меняйте после ответа кассовой системы. Это два разных статуса: успешная оплата не гарантирует, что касса уже приняла операцию.
Если товар передается покупателю в момент оплаты, настройте чек полного расчета после подтвержденного платежа. Backend передает в кассу позиции заказа: наименование, количество, цену, скидку, способ оплаты и другие реквизиты, которые нужны для вашей модели расчета.
Если продаете маркированную продукцию, заранее проверьте передачу кодов маркировки и сценарий возврата. Используйте чек-лист «Онлайн-касса с маркировкой: выбор, подключение и проверка готовности».
Для предоплаты заложите два разных события: получение денег и передачу товара либо оказание услуги. При поступлении предоплаты формируется чек на предоплату; при отгрузке или оказании услуги требуется событие полного расчета или зачета аванса в соответствии с выбранной моделью расчетов и настройками кассового решения.
Не ограничивайтесь одним чеком на оплату, если между деньгами и исполнением обязательства есть разрыв. В техническом задании прямо укажите, какая система отправляет событие отгрузки или закрытия услуги: CMS, складская система, личный кабинет исполнителя или 1С.
Для подписки обработайте каждое подтвержденное списание как отдельное платежное событие. Backend получает проверенный статус от платежного сервиса, создает или находит заказ периода, передает данные в кассу и записывает идентификаторы операции.
Не поручайте менеджеру вручную пробивать чеки по подписке. Вместо этого настройте очередь операций, повторную отправку при временной ошибке и уведомление ответственного сотрудника, если касса не подтвердила создание чека.
Выбирайте готовый модуль CMS, если используете распространенную платформу, у вас типовой каталог и стандартный платежный сценарий. До подключения проверьте, что модуль передает состав заказа, а не только итоговую сумму, и умеет обрабатывать возвраты.
Выбирайте прямую API-интеграцию, если сайт самописный, витрин несколько, есть подписки, предоплаты, доплаты или сложная логика заказа. В этом варианте разработчик контролирует проверку webhook, идемпотентность и очередь повторных запросов, но отвечает за их реализацию.
Подключайте 1С как учетный контур, когда в ней ведете номенклатуру, реализации, оплаты и возвраты. Передавайте в 1С номер и дату чека, статус фискализации, идентификаторы платежа и возврата. Не делайте 1С единственным источником статуса онлайн-платежа, если она не получает подтверждения из платежного сервиса.
| Критерий | CMS-модуль | Прямая API-интеграция | Связка с 1С |
|---|---|---|---|
| Когда выбирать | Типовой магазин на поддерживаемой CMS | Самописный сайт, несколько витрин, нестандартные процессы | Учет продаж и возвратов ведется в 1С |
| Скорость запуска | Выше, если модуль поддерживает ваш стек | Ниже: нужна разработка и тесты | Зависит от готового обмена и доработок 1С |
| Источник истины | CMS для заказа; эквайринг для факта оплаты | Backend фиксирует заказ и обработку платежа | 1С для учета; эквайринг подтверждает оплату |
| Предоплаты и зачет аванса | Проверьте поддержку конкретного модуля | Можно реализовать отдельными событиями | Удобно, если 1С получает событие отгрузки или услуги |
| Подписки и повторные списания | Нужна подтвержденная поддержка | Подходит при очереди операций и идемпотентности | Используйте для отражения оплат, не для приема webhook напрямую |
| Возвраты | Проверьте полный и частичный возврат | Настройте единый ключ возврата и повторные запросы | Сверяйте документ возврата с кассой и эквайрингом |
| Главное ограничение | Функции определяет модуль | Нужен разработчик и поддержка кода | Нельзя допустить расхождения статусов между системами |
| Кто отвечает за сбой | Владелец сайта и поставщик модуля по границе работ | Команда разработки или интегратор | Ответственный за обмен с 1С и платежный контур |
До выбора решения запросите у поставщика демонстрацию на вашем сценарии: успешная оплата, повторный webhook, предоплата с последующим зачетом, полный и частичный возврат. Ответ «поддерживается» без тестового маршрута данных не подтверждает готовность интеграции.
Нужен быстрый разбор схемы? Оставьте заявку: специалисты Интернет Касса проведут аудит текущего маршрута заказа и платежа, подберут вариант подключения, сформируют список доработок и помогут провести тестовый запуск.
Возврат у эквайера и кассовый возврат — связанные, но отдельные операции. Не считайте задачу закрытой, пока не проверили обе стороны: возврат денег покупателю и формирование корректного кассового документа.
Если эквайер подтвердил возврат, а касса вернула ошибку, не создавайте новый возврат денег. Поставьте кассовую операцию в очередь на повтор с тем же ключом, зафиксируйте инцидент и доведите до совпадения статусов. Если касса сформировала чек, а ответ эквайера не получен, сначала запросите статус возврата у провайдера по идентификатору операции; повторный запрос без проверки может привести к повторному возврату.
Чек формируют по непроверенному webhook. Проверяйте подпись и параметры платежа до изменения статуса заказа и отправки данных в кассу.
Один платеж фискализируют дважды. Используйте идемпотентный ключ и журнал обработанных операций. Повторная доставка уведомления должна находить существующую операцию.
Предоплату принимают за полный расчет. Разделите в интеграции получение денег и передачу товара или услуги. Иначе легко пропустить операцию зачета аванса либо сформировать неверный сценарий чека.
Возврат запускают вручную в разных системах. Запускайте его из единой карточки заказа или отдельного сервиса возвратов, который хранит связь платежа, чека и учетного документа.
В кассу передают только общую сумму. Передавайте состав заказа из CMS или 1С. Ручной ввод позиций, цены и скидки создает расхождение между чеком, оплатой и учетом.
До приема реальных платежей убедитесь, что ККТ зарегистрирована, фискальный накопитель работает, чеки передаются через ОФД, а тестовые операции видны в нужных системах. Информацию о применении ККТ и сервисах для работы с кассой смотрите на сайте ФНС России. Актуальные редакции нормативных документов удобно сверять через КонсультантПлюс.
Для запуска не достаточно одной успешной оплаты. Минимальный тестовый набор включает отказ, повторное уведомление, предоплату и зачет, полный и частичный возврат, а также сбой связи с кассой.
Интернет Касса помогает не только подобрать кассу: команда проводит аудит текущей схемы сайта, эквайринга и 1С, определяет владельцев статусов, готовит сценарии тестирования и сопровождает запуск. Обсудить интеграцию и получить план работ.