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