Тестовая оплата Robokassa открылась и вернула покупателя в магазин. Теперь нужно проверить, что сервер получил корректный результат и изменил нужный заказ. Ошибка в адресе уведомлений или в выборе пароля может оставить оплату и магазин в разных состояниях. Организуйте тест так, чтобы он проверял всю цепочку, а не только переход по кнопке.
Подготовьте данные магазина и способ интеграции
Зафиксируйте используемую CMS, модуль и версию либо описание собственного обработчика. Понадобятся настройки магазина Robokassa, необходимые пароли и адреса взаимодействия. Передавайте секреты защищённым способом и храните их на сервере. Скриншот кабинета со всеми значениями не должен становиться обычным вложением в общий чат.
Согласуйте, что означает создание заказа и когда он получает право на исполнение. Магазин цифровых материалов, например, должен открывать доступ по подтверждённому платежу. Само создание ссылки ещё не повод выдать файл. Для услуги с ручным подтверждением даты процесс может быть другим, и это нужно описать до разработки.
Используйте отдельную тестовую конфигурацию
В классическом сценарии Robokassa тестовые пароли отличаются от рабочих, а признак IsTest=1 включает тестовый запрос. Проверьте, что параметры запроса и настройка обработчика относятся к одному режиму. Не подменяйте только один пароль, оставляя остальную конфигурацию рабочей. В тесте не должно случайно создаваться настоящее обязательство для клиента.
Алгоритм контрольной подписи должен соответствовать выбранным настройкам и документации вашего сценария. Не копируйте устаревший пример только потому, что он найден первым. Зафиксируйте, какая версия протокола используется. Правила классического ResultURL и другого формата уведомления нельзя смешивать в одном обработчике без явного выбора.
Разделите уведомление и возврат пользователя
SuccessURL и FailURL предназначены для переходов покупателя. ResultURL в классическом сценарии используется для уведомления сервера. Успешная страница не должна сама присваивать заказу статус оплаты только на основании параметров адреса. Доверие к результату устанавливается на сервере по правилам выбранного протокола.
После проверки уведомления сопоставьте номер операции, сумму и ожидаемый заказ. Ответ обработчика должен соответствовать формату документации именно этого сценария. Неправильный ответ может привести к повторной доставке события. Повтор следует обрабатывать без повторной выдачи товара и без создания второго заказа.
Проверьте неприятные, но обычные ситуации
Закройте вкладку после тестового платежа и проверьте магазин отдельно. Затем повторите доставку корректного тестового события в безопасной среде. Добавьте неизвестный номер заказа и неправильную сумму: они не должны превращаться в успешную оплату. Такие проверки показывают, существует ли реальная связь с внутренним заказом.
Если сайт временно не принял результат, сотрудник должен видеть проблему и иметь порядок сверки. Храните идентификатор попытки, время и понятный результат обработки. Не записывайте пароли или полное секретное содержимое запроса в открытые журналы. Для обращения в поддержку подготовьте необходимые технические данные без лишней персональной информации.
Переключите режим по списку
До рабочего запуска проверьте боевые настройки, адрес уведомления, HTTPS, доступность обработчика и отсутствие тестового признака там, где ожидается реальная операция. Также проверьте, что старые тестовые заказы не учитываются как настоящие продажи. Изменение конфигурации должно иметь дату и ответственного.
После переключения наблюдайте за подтверждением операций и состояниями магазина. Возвраты, выдачу и расчётные документы принимайте отдельно, если они входят в задачу. Сохраните результаты тестов и инструкцию для менеджера: где увидеть платеж, как сверить заказ и кому передать ошибку. Это сокращает время разбора первого нестандартного обращения.
Связанные материалы
Проверка оплаты: успешный платёж, отказ, повтор и возврат
Оплата прошла, заказ не обновился: как сверять состояния
Кто отвечает за ошибку оплаты или доставки: как разобрать цепочку
Документация для проверки
Уведомления и перенаправления: Robokassa
Ссылки на документацию проверены 8 октября 2026 года. Названия настроек и возможности сервисов могут меняться; перед внедрением сверяйте актуальные условия.
Коротко о важном
Почему тестовый платёж открылся, но заказ не обновился?
Проверьте серверное уведомление, адрес обработчика, соответствие тестовых паролей и формата ответа. Возврат на сайт сам по себе не обновляет заказ безопасным способом.
SuccessURL можно использовать вместо ResultURL?
В классическом сценарии они выполняют разные роли. Переход покупателя не заменяет проверенное серверное уведомление об операции.
Нужно ли менять что-то кроме паролей при выходе из теста?
Проверьте всю конфигурацию: режим запроса, адреса, обработчик, алгоритм подписи и отделение тестовых заказов. Используйте список перехода для выбранного протокола.
Разработка и SEO в QuickLanding. Помогаем разобраться в задаче и выбрать подходящий состав работ.
Об эксперте
