Тестування інтеграцій 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 рази і стабільніший для асинхронних сценаріїв. Тестові картки різних систем:
| Платіжна система | Успіх | Відмова |
|---|---|---|
| ЮKassa | 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% бюджету на підтримці завдяки ранньому виявленню проблем.
Отримайте консультацію
Якщо у вас є питання щодо тестування платіжних інтеграцій на Бітрікс — зв'яжіться з нами. Ми оцінимо ваш проєкт і запропонуємо оптимальний план тестування.