Тестирование интеграций 1С-Битрикс с платёжными системами
Платёжный шлюз подтвердил оплату, webhook пришёл, но заказ остался в статусе «Ожидает оплаты». Или хуже — один и тот же webhook обработался дважды, и система создала два оплаченных заказа. Стандартные тесты часто пропускают эти сценарии. За 5 лет работы с интеграциями 1С-Битрикс и платежными системами (ЮKassa, Сбер, Тинькофф, Robokassa) мы научились выявлять такие проблемы до деплоя. Наша методология покрывает все асинхронные события: редирект на шлюз, webhook-уведомления (в том числе задержанные и дублирующие), обработку статусов и фискализацию по 54-ФЗ. По статистике, 80% инцидентов с платежами происходят из-за некорректной обработки webhook'ов — мы устраняем эти риски на этапе тестирования.
Какие риски покрывает тестирование?
Основные сценарии, которые мы обязательно проверяем:
- Успешная оплата — стандартный флоу: корзина → оформление → редирект → оплата → возврат на сайт → смена статуса заказа.
- Отклонённый платёж — карта отклонена, статус заказа должен остаться «Ожидает оплаты», а не «Отменён».
- Сценарий «закрыл браузер» — покупатель ушёл после редиректа, не завершив оплату; webhook не пришёл; заказ должен корректно обрабатываться при повторном визите.
- Задержанный webhook — webhook приходит через 10–20 минут после оплаты (часто у Robokassa, Сбера); статус заказа должен обновиться корректно.
- Дублирующий webhook — одно и то же уведомление приходит дважды; повторная обработка не должна задваивать статус «Оплачен».
- Частичный возврат — через 1–2 дня после оплаты, проверяем POST /refunds и чек возврата.
- Полный возврат — с проверкой фискального чека (если подключена касса по 54-ФЗ).
Как защититься от дублирующих webhook'ов?
Согласно официальной документации 1С-Битрикс по платёжным системам, обработчик должен быть устойчив к дублирующим уведомлениям. Стандартный 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'и могут привести к задвоению оплаты. Мы также проверяем обработку задержанных уведомлений — это частая проблема.
Почему важно тестировать задержанные webhook'и?
Задержки в доставке webhook'ов — стандартное поведение многих платёжных систем. Если обработчик не рассчитан на получение уведомления спустя 15–30 минут после оплаты, заказ может остаться в статусе «Ожидает оплаты». Клиент уйдёт, а деньги уже списаны. Мы моделируем такие задержки с помощью инструментов вроде ngrok и проверяем, что статус обновляется корректно даже при опоздании.
Технические точки проверки
Ключевая таблица для проверки статусов — 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-уведомлений в локальном окружении используем ngrok или localtunnel — они пробрасывают внешний URL на локальный сервер. Без этого тестировать асинхронные уведомления от платёжных систем невозможно.
Для автоматизации сценариев применяем Playwright или Cypress с реальными тестовыми картами. Playwright быстрее Selenium в 3 раза и стабильнее для асинхронных сценариев. Тестовые карты разных систем:
| Платёжная система | Успех | Отказ |
|---|---|---|
| ЮКасса | 5555555555554477 |
5555555555554444 |
| Тинькофф | 4300000000000777 |
4300000000000885 |
| Robokassa | — | тестовый режим в настройках |
| Сбер | 4276300010000006 |
4276300010000014 |
Что входит в работу
Мы предоставляем полный комплекс: тест-план с описанием сценариев, документацию по найденным дефектам, настроенный песочницу (sandbox) для повторного тестирования, обучение ваших инженеров обработке типовых ошибок, а также поддержку в течение 30 дней после сдачи. Это гарантирует, что интеграция останется стабильной после нашего ухода.
Сроки и стоимость
| Объём работ | Срок |
|---|---|
| Тестирование 1 платёжной системы (стандартные сценарии) | 1–2 дня |
| Тестирование 2–3 систем + возвраты | 3–5 дней |
| Полный цикл с 54-ФЗ и автотестами | 6–10 дней |
Стоимость рассчитывается индивидуально и зависит от сложности интеграции, количества систем и необходимости разработки автотестов. Тестирование окупается за счёт предотвращения потерь от сбоев — один ночной инцидент может стоить дороже всего проекта. Закажите тестирование интеграции — это сэкономит время и деньги.
Наш опыт
Команда имеет сертификаты Bitrix Partner и 5+ лет опыта в тестировании платёжных интеграций. Мы протестировали более 100 проектов, включая интеграции с ЮKassa, Сбер, Тинькофф, Robokassa, Paypal и другими. Наши клиенты экономят до 30% бюджета на поддержке благодаря раннему выявлению проблем.
Получите консультацию
Если у вас есть вопросы по тестированию платёжных интеграций на Битрикс — свяжитесь с нами. Мы оценим ваш проект и предложим оптимальный план тестирования.