Тестирование интеграций 1С-Битрикс с платежными системами

Тестирование интеграций 1С-Битрикс с платёжными системами

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

Что и как тестировать

Перед запуском тестов необходимо развернуть проект с корректными тестовыми credentials платёжной системы. Большинство агрегаторов (ЮКасса, Сбер, Тинькофф, Robokassa) предоставляют sandbox-окружение с отдельным shopId и secretKey. Их вводят в настройках платёжной системы: Магазин → Платёжные системы → {Система} → Настройки.

Сценарии, которые обязательны для тестирования:

1. Успешная оплата — стандартный флоу: корзина → оформление → редирект → оплата → возврат на сайт → смена статуса заказа
2. Отклонённый платёж — карта отклонена, статус заказа должен остаться «Ожидает оплаты», не «Отменён»
3. Сценарий «закрыл браузер» — покупатель ушёл после редиректа, не завершив оплату; webhook не пришёл; заказ должен корректно обрабатываться при повторном визите
4. Задержанный webhook — webhook приходит через 10–20 минут после оплаты (частое явление у Robokassa, Сбера); статус заказа должен обновиться корректно
5. Дублирующий webhook — одно и то же уведомление приходит дважды; повторная обработка не должна задваивать статус «Оплачен»
6. Частичный возврат — через 1–2 дня после оплаты, проверяем POST /refunds и чек возврата
7. Полный возврат — с проверкой фискального чека (если подключена касса по 54-ФЗ)

Технические точки проверки

Ключевая таблица для проверки статусов — b_sale_pay_system_action (конфигурация обработчика) и b_sale_order_payment (платежи заказов). После каждой транзакции в тесте:

SELECT o.account_number, p.paid, p.date_paid, p.ps_status, p.ps_status_message
FROM b_sale_order_payment p
JOIN b_sale_order o ON o.id = p.order_id
WHERE o.account_number = '12345'
ORDER BY p.date_paid DESC;

Проверяем, что ps_status содержит оригинальный статус от платёжной системы, а не просто Y/N. Это критично для постфактумной диагностики.

Webhook-обработчик — самое уязвимое место. Стандартный URL в Битрикс: /bitrix/tools/sale_ps_result.php. При тестировании обязательно проверяем:

// Идемпотентность обработчика — защита от дублей
$cache = Cache::createInstance();
$cacheId = 'payment_processed_' . $paymentId;
if ($cache->initCache(86400, $cacheId, '/sale/payment')) {
    return; // Уже обработано
}
// ... логика обработки ...
$cache->startDataCache();
$cache->endDataCache(['processed' => true]);

Инструментарий

Для тестирования webhook-уведомлений в локальном окружении используют ngrok или localtunnel — они пробрасывают внешний URL на локальный сервер. Без этого тестировать асинхронные уведомления от платёжных систем невозможно.

Для автоматизации сценариев — Playwright или Cypress с реальными тестовыми картами. Тестовые карты разных систем:

Сроки