В lk.interkassa.online до старта проверьте цепочку «заказ — платеж — серверное подтверждение — кассовый документ — ОФД — электронный чек». Оплата в форме еще не означает, что заказ можно выдать: финальный статус должен подтвердить сервер, а фискализация — завершиться без ошибки.
Важно: состав разделов, названия пунктов меню и доступ к платежам, кассе, возвратам или отчетам определяет ваш договор и подключенные модули. Не включайте функцию по названию из чужой инструкции. После входа фиксируйте фактические названия экранов вашей учетной записи и проверяйте их на тестовой операции.
Если нужно не только открыть кабинет, а принять интеграцию и найти разрывы между оплатой и чеком, оставьте заявку в Интернет Касса. На аудите разбираем платежные события, webhook, кассовые документы, ОФД и возвраты до выхода в боевой режим.
Откройте адрес lk.interkassa.online и войдите по учетным данным, выданным для вашей организации. Если входа нет или пароль не подходит, не создавайте вторую учетную запись без согласования: сначала подтвердите, к какой организации, магазину и договору должен относиться доступ.
Дальше проверьте не «все настройки», а пять конкретных точек:
Не называйте платеж успешным только потому, что покупатель вернулся на страницу «Спасибо». Этот переход происходит через return URL и не доказывает, что деньги зачислены. Заказ переводит в оплаченный статус ваш сервер — после проверки подписанного уведомления либо запроса статуса к платежному сервису.
Передавайте в платежную и кассовую цепочку номер заказа, позиции, количество, цену, скидку, итоговую сумму и контакт для электронного чека. В приемке проведите успешную оплату, отказ в оплате и полный возврат. Для успешной полной оплаты проверьте, что сформирован документ по сценарию полной оплаты, сумма и состав заказа совпадают, а ОФД принял документ.
Определите источник описания услуги: сайт, CRM или менеджер. Затем проверьте, что при создании ссылки в заказ передаются сумма, назначение и контакт покупателя, а не только сумма. Для оплат по СБП используйте отдельный регламент: как настроить чек по ссылке СБП.
Не оформляйте эти события одним шаблоном. Для предоплаты проверьте документ, который соответствует получению предоплаты; при передаче товара или оказании услуги — документ по сценарию зачета предоплаты; для доплаты — отдельную операцию на доплачиваемую сумму. Конкретные признаки способа расчета и предмета расчета согласуйте с настройками ККТ и учетной системой до первой продажи.
Протестируйте первое списание, повторное списание, отмену подписки и возврат отдельно. На каждое событие создайте уникальный идентификатор операции. Повторно доставленное уведомление не должно повторно списывать деньги, создавать второй заказ или формировать дублирующий документ.
Сначала зафиксируйте, кто принимает деньги, от чьего имени и за чей счет ведется расчет. Потом настраивайте реквизиты чека и роли участников. Порядок проверки разобран в статье «Агентский чек на услуги: реквизиты, роли и запуск кассы».
| Критерий | Типовой запуск | Нужна доработка или аудит | Что сделать |
|---|---|---|---|
| Канал продаж | Один сайт, готовый модуль | CRM, несколько витрин, приложение или офлайн-канал | Составьте карту: источник платежа → заказ → касса. |
| Расчет | Разовая полная оплата | Предоплата, доплата, подписка, частичный возврат | Опишите отдельный кассовый сценарий для каждого события. |
| Интеграция | Готовый модуль без изменений | API или собственная логика заказа | Проверьте подпись webhook, идемпотентность и запрос статуса. |
| Касса | Один продавец и одна ККТ | Несколько юрлиц, касс или схем приема денег | Сверьте, какая касса формирует документ по каждому каналу. |
| Возвраты | Редкие полные возвраты вручную | Частичные, автоматические или массовые возвраты | Примите платежный и кассовый возврат одной проверкой. |
Количество платежей не определяет сложность запуска. Риск появляется, когда один заказ проходит несколько событий: предоплата, доплата, зачет, отмена или частичный возврат. Для каждого события нужен ответственный, финальный платежный статус и проверяемый результат фискализации.
Платеж успешен, а чека нет. Не закрывайте заказ автоматически и не пытайтесь повторно принять оплату. Найдите операцию по ID платежа, проверьте журнал передачи в кассу, реквизиты заказа, статус документа и обмен с ОФД. Перед исправлением зафиксируйте время, сумму, номер заказа и причину сбоя; дальше оформляйте документ по согласованному с кассовым специалистом сценарию, чтобы не создать дубль.
Чек есть, а заказа нет. Найдите источник запроса: CRM, сайт, ручная операция или повтор webhook. Сверьте сумму, время и ID платежа. Если уведомление обработано дважды, исправляйте логику идемпотентности, а не создавайте новый заказ задним числом.
Возврат денег проведен, а возвратный документ не проверен. Откройте платежную операцию и связанный кассовый документ. При полном возврате сумма возвратного документа должна соответствовать возвращенной сумме; при частичном — возвращаемой части заказа. Затем проверьте результат передачи в ОФД.
Менять статус заказа по return URL. Покупатель может вернуться на сайт без успешной оплаты, а успешный платеж может пройти без возврата в браузер. Исправление: меняйте статус только по проверенному webhook или серверной проверке статуса.
Принимать любой webhook без проверки. Такой обработчик можно вызвать извне или он может повторно обработать одно сообщение. Исправление: проверяйте подпись и источник по документации сервиса, храните ID уведомления и обрабатывайте повтор без новых операций.
Передавать в кассу только сумму. Тогда чек может не соответствовать заказу. Исправление: согласуйте карту полей — позиции, количество, цена, скидка, итог, контакт и параметры расчета.
Тестировать только оплату. Ошибка часто проявляется при возврате, отказе банка или повторном уведомлении. Исправление: примите весь набор сценариев из чек-листа запуска.
Не контролировать ОФД. Документ, который не передался из-за ошибки обмена, нельзя считать полностью закрытым. Исправление: включите ошибки ОФД в ежедневную сверку.
Правила применения ККТ, регистрации кассы и передачи фискальных данных сверяйте на сайте ФНС России. Для изменений реквизитов продавца или параметров ККТ используйте инструкцию по перерегистрации онлайн-кассы.
Если у вас API, агентская модель, подписки, предоплата или несколько юридических лиц, не переносите настройки из типового модуля без приемки. Сначала составьте карту всех платежных событий, затем проверьте ее с бухгалтерией, интегратором и настройками ККТ.
Да, если в вашем договоре подключены платежный и фискальный модули. После входа найдите операцию по ID платежа или номеру заказа и сверяйте ее с данными кассового документа; состав экранов и полей зависит от подключенной конфигурации.
Да, применяйте ККТ при интернет-расчетах, если операция не входит в исключения из требований 54-ФЗ. Для предоплаты, зачета предоплаты, агентской схемы и возвратов заранее настройте отдельные кассовые сценарии.
Нет, return URL не подтверждает оплату. Меняйте статус заказа только после проверки серверного уведомления с подписью или после серверного запроса статуса платежа.
Сразу остановите автоматическое закрытие этого заказа и заведите инцидент с ID платежа, номером заказа, суммой и временем операции. Проверьте передачу данных в кассу, статус фискального документа и обмен с ОФД; после устранения причины оформите документ по согласованному с кассовым специалистом сценарию.
Да, если используется готовый модуль, один сайт и разовые оплаты. Перед запуском все равно выполните успешную и неуспешную оплату, проверку webhook, возврат, чек, доставку чека и статус ОФД; для API, подписок или нескольких каналов продаж подключите интегратора.