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