Robokassa Sandbox: тестовый режим, кейсы и чек‑лист запуска

Robokassa Sandbox: тестовый режим, кейсы и чек‑лист запуска

Добро пожаловать в подробный гид по тестированию платежей в Robokassa. Здесь вы найдете все о том, как работает тестовый режим Robokassa (Sandbox Robokassa), как проводить тестовые платежи Robokassa безопасно и эффективно, какие кейсы обязательно проверить и с чем выйти в прод.

Что такое Sandbox Robokassa и чем он отличается от прода

Тестовый режим Robokassa — это изолированная среда (песочница), в которой вы эмулируете весь платежный поток без движения реальных средств. Sandbox Robokassa имитирует поведение платежных методов, 3‑D Secure, статусы транзакций и отправку уведомлений, чтобы вы могли закрыть технические кейсы до запуска на живых клиентах.

Ключевые свойства песочницы:

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

Совет: фиксируйте различия Sandbox/прод заранее (тайминги, доступность методов, формат некоторых полей) в Readme вашего проекта.

![Диаграмма потоков Sandbox Robokassa — placeholder]

Как включить тестовый режим в личном кабинете

Для доступа к песочнице достаточно аккаунта мерчанта. Выполните базовые шаги:

1. Войдите в кабинет мерчанта — см. инструкцию: вход в личный кабинет.

2. Откройте технические настройки. Если вы впервые в интерфейсе, ознакомьтесь с обзором: личный кабинет — обзор.

3. Активируйте «Тестовый режим» (Sandbox), получите тестовые ключи и параметры интеграции (MerchantLogin, пароли, публичные ключи и т.д.).

4. Настройте URL возврата и URL уведомлений (вебхуки) для тестовой среды. Позже вы сможете продублировать их для прода.

5. Проверьте выбранные способы оплаты и валюты. Для справки по методам оплаты смотрите раздел: способы оплаты Robokassa.

Если вы интегрируетесь по API, начните с руководства: интеграция Robokassa API.

Тестовые данные: карты, счета и сценарии

Тестовые платежи Robokassa могут выполняться разными путями: через банковские карты, альтернативные методы, инвойсы/счета и т.д. Для каждого способа в песочнице доступны «эмуляторы» итогов: успешный платёж, отклонение, отмена, 3‑D Secure пошагово.

Где брать тестовые данные:

• Тестовые карты Robokassa и инструкции к ним опубликованы в песочнице личного кабинета. Там же обычно указаны коды или условия, вызывающие разные статусы (успех, отказ, 3‑DS challenge и т.д.).
• Для счетов и выставления инвойсов используйте раздел «Счета/Invoice» — подробнее: Robokassa Invoice и счета.

Подход к сценариям:

• Убедитесь, что у вас есть минимум по одной «успешной» и «неуспешной» тестовой карте.
• Проверьте как минимум один сценарий с 3‑D Secure (успешный и неуспешный). О безопасности и 3‑DS: безопасность, PCI DSS и 3‑D Secure.

Пример матрицы проверки в Sandbox:

Что тестируем	Как проверить	Где смотреть	Ожидаемый результат
Инициация платежа	Создать заказ через API/форму	Логи приложения, Sandbox-кабинет	Создан счёт, клиент переадресован
3‑D Secure	Использовать тестовую карту с 3‑DS	Тестовая платежная страница	Прохождение/провал 3‑DS корректно отражён
Успех оплаты	Пройти «успех» сценарием Sandbox	Журнал транзакций, вебхуки	Статус paid, корректный webhook
Отказ/отмена	Вызвать «отклонение»	Логи + UI	Статус failed/canceled обрабатывается
Возврат (refund)	Запустить полный/частичный	Кабинет + API	Статус refund, баланс заказа обновлён

Примечание: конкретные тестовые номера карт, CVV и даты берите в вашем кабинете Sandbox — они периодически обновляются провайдером.

Проверка вебхуков Robokassa: пошаговый алгоритм

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

Рекомендуемый алгоритм:

1. Поднимите публично доступный URL для уведомлений. Для локальной разработки используйте туннели (ngrok, cloudflared и т.п.).
2. Логируйте весь сырый запрос (заголовки, параметры, тело) в отдельный канал для отладки.
3. Проверьте подпись. Обычно формируется хэш на основе фиксированного набора параметров и секретов мерчанта в строго заданном порядке. Сравнивайте подпись без учета регистра и пробелов, следуйте документации Robokassa.
4. Провалидируйте сумму, валюту, идентификатор заказа и повторяемость. Сравните с данными, которые вы сохранили при инициации.
5. Сделайте обработку идемпотентной. Вебхуки могут приходить повторно — обновляйте статус один раз, опираясь на уникальный идентификатор платежа/инвойса.
6. Возвращайте положительный ответ (HTTP 200) в формате, описанном в документации. В песочнице проверьте, как система реагирует на ошибки и ретраи.

Дополнительно:

• Фильтрация по IP часто не гарантирует доставку в облачных инфраструктурах — полагайтесь на криптографическую подпись.
• Если вы используете несколько сред, отличайте секреты и callback-URL для Sandbox и прода.

Полную схему интеграции и форматы полей смотрите в разделе: интеграция Robokassa API.

Стенды тестирования: локальный, Sandbox и pre-prod

В типичном процессе используется цепочка из нескольких сред. Помимо песочницы встречается pre-prod Robokassa — промежуточная среда, максимально близкая к продакшену и выдаваемая по согласованию для проектов с повышенными требованиями.

Среда	Для чего	Доступ/URL	Примечания
Локальный mock	Быстрая разработка без сети	Локальный сервер	Подменяйте ответы провайдера
Sandbox Robokassa	Полная эмуляция платежей	Данные в кабинете	Тестовые карты/триггеры, без реальных денег
pre-prod Robokassa	Финальная проверка интеграции	По запросу	Ближе к прода, может требовать аппрув
Прод	Живая среда	Рабочие ключи	Реальные платежи и комиссии

Рекомендация: держите конфигурации раздельно и помечайте события логами среды (env=local/sandbox/pre-prod/prod), чтобы быстрее искать причины расхождений.

Типовые кейсы: что протестировать до релиза

Проведите минимум такой набор тестов в Sandbox Robokassa:

• Успешная оплата банковской картой с 3‑D Secure.
• Отказ по карте (недостаточно средств/общий decline) — через тестовые карты Robokassa или триггер.
• Отмена платежа пользователем на платёжной странице.
• Повторная отправка вебхука и идемпотентность.
• Полный и частичный возвраты — см. возвраты и chargeback.
• Разные способы оплаты (если их планируете): способы оплаты Robokassa.
• Выставление счёта и оплата по ссылке: Invoice и счета.
• Рекуррентные платежи (подписки): рекуррентные платежи.
• Мобильные и QR‑платежи: мобильные платежи и QR.
• Кастомизация платёжной формы (язык, логотип, автозаполнение): настройка платёжной формы.
• Формирование отчетности после тестовых транзакций: отчёты и аналитика.

Чек‑лист запуска: готовность к продакшену

Перед переключением с Sandbox на прод проверьте следующее:

• Ключи и пароли: установлены боевые реквизиты, тестовые удалены из конфигурации.
• URL возврата/уведомлений: прод-адреса заданы в кабинете и в коде, тестовые отключены.
• Подпись и валидации: хэш проверяется корректно, сравнение строк устойчиво к регистру и пробелам.
• Идемпотентность: повторные вебхуки не дублируют операции, статусы переходят в верные конечные.
• Обновление статуса заказа: платёж обновляет paid/failed/canceled/refunded в вашей БД.
• Логи и мониторинг: включен уровень информации для прод, ошибки уходят в алерты.
• Способы оплаты: включены те, что прошли тесты; скрыты лишние.
• Тарифы и выплаты: согласованы и проверены — см. тарифы, комиссии и выплаты.
• UX: форма оплаты и страницы результата адаптированы под мобильные, локализация корректна.
• Безопасность: используете HTTPS, хранение секретов в Vault/ENV, учтен 3‑D Secure — см. безопасность, PCI и 3‑DS.

Частые ошибки и отладка

Даже в тестовом режиме возникают типовые ошибки. Как их ловить:

• Signature mismatch: порядок полей/кодировка/соль. Сверьте порядок параметров по документации, проверьте лишние пробелы и регистр.
• Неверная сумма/валюта: сравнивайте полученную сумму с заказом в вашей БД до смены статуса.
• Ошибки роллбэков: при отмене/рефанде не забывайте обновлять баланс/статус внутреннего заказа.
• Test/Prod мешанина: ключи от Sandbox в прод-конфиге или наоборот. Держите конфиги раздельно по ENV.
• Блокирующая логика: обработчик вебхука делает тяжёлую работу синхронно — вынесите бизнес‑логику в очередь.

Разбор распространенных проблем (Auth, Merchant, подпись и пр.) — в гайде: troubleshooting ошибок.

Особые сценарии: рекуррентные, счета, возвраты, QR

• Подписки и автосписания: проверьте создание и обновление токенов, продление, неуспех списания — рекуррентные платежи.
• Инвойсы и оплата по ссылке: проверка генерации ссылки, статуса и уведомлений — Invoice и счета.
• Возвраты и претензии: полный/частичный refund, обратные вебхуки, разбор спорных операций — возвраты и chargeback.
• Мобильные/QR: открытие формы на смартфоне, deep‑link, редиректы — мобильные платежи и QR.
• Аналитика: сведение отчётов Sandbox с вашей БД, экспорт — отчёты и аналитика.

Итоги и следующий шаг

Тестовый режим Robokassa — безопасный способ отладить весь жизненный цикл оплаты: инициация, 3‑D Secure, вебхуки, возвраты и отчеты. Используйте Sandbox Robokassa для закрытия ключевых кейсов, применяйте стенды тестирования (включая при необходимости pre-prod Robokassa), а затем проходите чек‑лист запуска перед переключением на прод.

Готовы перейти к интеграции или шлифовке UX платёжной формы? Начните с гайда по API и формам: интеграция Robokassa API и настройка платёжной формы. Удачных релизов и безупречных тестовых платежей!