Тестовый режим платёжной системы

Тестовый режим (sandbox) — это способ прогнать полный сценарий оплаты в 1С-Битрикс, не списывая деньги: покупатель проходит по песочнице провайдера, а заказ должен сам перейти в статус «оплачен» по колбэку. Разберём, где он включается, чем отличается от боевого и как не забыть переключиться перед запуском.

Зачем нужен тестовый режим

Оплата в магазине — это цепочка: витрина → страница провайдера → возврат покупателя на сайт → колбэк от банка, который меняет статус заказа. Любое звено может сломаться: неверный ключ, недоступный callback-URL, неправильная подпись, жёсткое ограничение показа. Проверять это на реальных деньгах дорого и неудобно.

Тестовый режим воспроизводит весь сценарий на песочнице провайдера: карта «списывается», приходит уведомление, заказ переходит в оплаченный статус — но фактического движения средств нет. Что именно вы проверяете:

• корректность связки «магазин ID + секретный ключ» с обработчиком;
• возврат покупателя на страницы /personal/order/ после оплаты и отказа;
• приём колбэка и автоматическую простановку флага PAYED = Y у объекта Payment;
• формирование чека по 54-ФЗ, если он завязан на платёжную систему.

Где включается тестовый режим

Настройка живёт в карточке платёжной системы: Магазин → Настройки → Платёжные системы → нужная система → вкладка «Настройка обработчика». Способ включения зависит от обработчика, и вариантов на практике три:

1. Отдельный флаг «Работа в тестовом режиме». В обработчиках вроде Robokassa есть переключатель Да/Нет — при «Да» запрос уходит на тестовый контур провайдера.
2. Отдельная тестовая учётка. У ЮKassa переключение делается не галочкой, а подстановкой тестового shopId и тестового секретного ключа — по ним запросы автоматически идут в песочницу.
3. Демо-обработчик. Коробочная «Банковская карта (демо)» вообще не обращается к банку и просто эмулирует оплату — удобно для проверки сценария заказа в отрыве от конкретного эквайринга.

Поле тестового режима — это, как правило, бизнес-значение обработчика, описанное в его .description.php. Поэтому набор настроек у каждого провайдера свой: универсальной галочки «тест» на все системы в Битрикс нет.

Тестовые ключи и учётки провайдера

Главный принцип: боевые и тестовые доступы — это разные учётные данные, а нередко и разные адреса эндпоинтов. Взять «продовые» ключи и просто поставить галочку «тест» обычно не получится — песочница их не примет.

Заводите тестовые доступы в личном кабинете провайдера заранее и храните их отдельно от боевых — например, во второй платёжной системе-копии. Это позволяет держать «боевую» и «тестовую» настройки рядом и переключать магазин между ними без риска перепутать ключи.

Тестовые карты и сценарии оплаты

В песочнице реальную карту вводить нельзя — провайдер даёт набор тестовых карт в своей документации. Разные номера эмулируют разные исходы, и проверять нужно не только «успех»:

• Успешная оплата — заказ должен получить статус «оплачен» автоматически.
• Отказ банка — покупатель корректно возвращается на сайт, заказ остаётся неоплаченным, корзина не теряется.
• 3-D Secure — проверка редиректа на страницу подтверждения и обратно.

Точные номера тестовых карт, коды CVC и даты берите из документации конкретного провайдера — они у всех разные, и придумывать их нельзя. После оплаты сверьте картину в двух местах: карточка заказа в Магазин → Заказы и журнал операций в личном кабинете провайдера. Флаг оплаты и сумма должны совпадать.

Колбэки и публичный URL

Самая частая причина «оплата прошла, а заказ висит неоплаченным» даже в тесте — недоступный callback-URL. Провайдер отправляет уведомление о статусе на адрес обработчика (в новом ядре это маршрут вида /bitrix/tools/sale_ps_result.php или persona-URL сервиса), и именно этот запрос переводит объект Payment в оплаченный статус.

Отсюда практические требования к тестовому стенду:

• сайт должен быть доступен по публичному домену и по HTTPS — на localhost колбэк от провайдера просто не дойдёт;
• для локальной разработки поднимайте туннель (например, ngrok) или тестируйте на dev-поддомене;
• адрес колбэка и «URL успеха/неудачи» в кабинете провайдера должны указывать на этот же домен;
• если стенд закрыт авторизацией по IP или Basic-Auth, входящий запрос провайдера нужно из-под неё вывести.

Логи и отладка

Когда в песочнице что-то не сходится, диагностику ведут по логам, а не наугад. У многих обработчиков в настройках есть чекбокс «Отладочный режим» (или «Ведение журнала») — включите его на время тестов.

Куда смотреть в 1С-Битрикс:

• Магазин → Настройки → Журнал платёжных систем — записи входящих и исходящих запросов обработчика;
• журнал операций и вебхуков в личном кабинете провайдера — что он реально прислал и с каким кодом ответа;
• серверные логи веб-сервера — по ним видно, дошёл ли POST на callback-URL и каким статусом ответил сайт.

Сопоставление «что отправил провайдер» ↔ «что принял и как ответил Битрикс» почти всегда точно локализует проблему: неверная подпись, пустой ответ, редирект вместо 200 OK или ошибка в разборе параметров.

Переход в боевой режим

Тест пройден — но именно на переключении в бой чаще всего и «выстреливает» невнимательность. Пройдите короткий чек-лист перед запуском:

1. снимите флаг тестового режима либо подставьте боевые shopId/ключи вместо тестовых;
2. смените адреса эндпоинтов и колбэков на продовые, если они отличались;
3. проверьте, что сайт открыт по HTTPS на боевом домене и колбэк-URL доступен снаружи;
4. убедитесь, что демо-обработчик «Банковская карта (демо)» отключён и не показывается покупателю;
5. проведите одну реальную оплату на минимальную сумму и сделайте по ней возврат — это финальная проверка боевого контура и заодно возвратов.

Итог

Тестовый режим в 1С-Битрикс — это не галочка ради галочки, а полноценная приёмка оплаты: тестовые ключи провайдера, карты из его документации, доступный по публичному HTTPS колбэк и автоматический переход заказа в статус «оплачен». Проверив сценарий в песочнице и аккуратно переключившись в бой, вы избегаете самого болезненного класса ошибок — когда деньги «теряются» уже на живых клиентах.

Если нужно подключить эквайринг, прогнать его через песочницу и вывести в бой без простоя витрины, а заодно связать оплату с обменом заказами в 1С — мы настраиваем и сопровождаем магазины на Битрикс под ключ и берём тестирование платежей на себя.