# Подключение Robokassa: как организовать тест и переход в рабочий режим

Источник: https://quicklanding.ru/knowledge/robokassa-site-integration/

Как проверить Robokassa перед рабочим запуском: тестовый режим, отдельные пароли, серверное уведомление, сверка суммы и переход к настоящим платежам.

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

## Подготовьте данные магазина и способ интеграции

![Оплата картой на кассе](/assets/images/knowledge/robokassa-site-integration.webp)

Зафиксируйте используемую CMS, модуль и версию либо описание собственного обработчика. Понадобятся настройки магазина Robokassa, необходимые пароли и адреса взаимодействия. Передавайте секреты защищённым способом и храните их на сервере. Скриншот кабинета со всеми значениями не должен становиться обычным вложением в общий чат.

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

## Используйте отдельную тестовую конфигурацию

В классическом сценарии Robokassa тестовые пароли отличаются от рабочих, а признак IsTest=1 включает тестовый запрос. Проверьте, что параметры запроса и настройка обработчика относятся к одному режиму. Не подменяйте только один пароль, оставляя остальную конфигурацию рабочей. В тесте не должно случайно создаваться настоящее обязательство для клиента.

Алгоритм контрольной подписи должен соответствовать выбранным настройкам и документации вашего сценария. Не копируйте устаревший пример только потому, что он найден первым. Зафиксируйте, какая версия протокола используется. Правила классического ResultURL и другого формата уведомления нельзя смешивать в одном обработчике без явного выбора.

## Разделите уведомление и возврат пользователя

SuccessURL и FailURL предназначены для переходов покупателя. ResultURL в классическом сценарии используется для уведомления сервера. Успешная страница не должна сама присваивать заказу статус оплаты только на основании параметров адреса. Доверие к результату устанавливается на сервере по правилам выбранного протокола.

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

## Проверьте неприятные, но обычные ситуации

Закройте вкладку после тестового платежа и проверьте магазин отдельно. Затем повторите доставку корректного тестового события в безопасной среде. Добавьте неизвестный номер заказа и неправильную сумму: они не должны превращаться в успешную оплату. Такие проверки показывают, существует ли реальная связь с внутренним заказом.

Если сайт временно не принял результат, сотрудник должен видеть проблему и иметь порядок сверки. Храните идентификатор попытки, время и понятный результат обработки. Не записывайте пароли или полное секретное содержимое запроса в открытые журналы. Для обращения в поддержку подготовьте необходимые технические данные без лишней персональной информации.

## Переключите режим по списку

До рабочего запуска проверьте боевые настройки, адрес уведомления, HTTPS, доступность обработчика и отсутствие тестового признака там, где ожидается реальная операция. Также проверьте, что старые тестовые заказы не учитываются как настоящие продажи. Изменение конфигурации должно иметь дату и ответственного.

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

## Связанные материалы

[Проверка оплаты: успешный платёж, отказ, повтор и возврат](/knowledge/payment-test-scenarios/)

[Оплата прошла, заказ не обновился: как сверять состояния](/knowledge/payment-status-reconcile/)

[Кто отвечает за ошибку оплаты или доставки: как разобрать цепочку](/knowledge/delivery-payment-boundaries/)

## Документация для проверки

[Тестовый режим: Robokassa](https://docs.robokassa.ru/ru/testing-mode)

[Начало интеграции: Robokassa](https://docs.robokassa.ru/ru/quick-start)

[Уведомления и перенаправления: Robokassa](https://docs.robokassa.ru/ru/notifications-and-redirects)

Ссылки на документацию проверены 8 октября 2026 года. Названия настроек и возможности сервисов могут меняться; перед внедрением сверяйте актуальные условия.

## Частые вопросы

### Почему тестовый платёж открылся, но заказ не обновился?

Проверьте серверное уведомление, адрес обработчика, соответствие тестовых паролей и формата ответа. Возврат на сайт сам по себе не обновляет заказ безопасным способом.

### SuccessURL можно использовать вместо ResultURL?

В классическом сценарии они выполняют разные роли. Переход покупателя не заменяет проверенное серверное уведомление об операции.

### Нужно ли менять что-то кроме паролей при выходе из теста?

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

Автор: Владимир Николаев