Тестування інтеграцій 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. Повне повернення — з перевіркою фіскального чека (якщо підключено касу)

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

Ключова таблиця для перевірки статусів — 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 із реальними тестовими картками. Тестові картки різних систем:

Терміни