QA на практиці

Відкрито

PAY

PAY-001 КРИТИЧНИЙ

Таймаут платіжного шлюзу

Оплата не проходить, коли відповідь провайдера займає більше 15 секунд. Користувачі втрачають замовлення та гроші.

Платежі Таймаут Продакшн

Оточення: Продакшн, Chrome 120, мережа 3G

Кроки відтворення:

1. Додати товар до кошика
2. Перейти до оформлення
3. Ввести дані картки
4. Натиснути "Оплатити" на повільному з'єднанні

Фактичний результат: Помилка таймауту "Сесія закінчилась" після 15с

Очікуваний результат: Платіж обробляється або показується кнопка повторити

Рекомендації:

• Збільшити таймаут до 30 секунд
• Додати механізм повторів (3 спроби)
• Показувати індикатор прогресу

Показати деталі

Відкрито

PAY

RULE-001 КРИТИЧНИЙ

Processing продовжує пошук транзакцій після відхилення Travel Rule

Сервіс processing-service продовжує пошук і обробку транзакцій навіть після того, як сервіс Travel Rule повертає статус відхилення (DECLINED).

Платежі Travel Rule Транзакції

Оточення: Продакшн, Процесинг, Travel Rule

Кроки відтворення:

1. Створити інвойс або транзакцію
2. Дочекатися запуску перевірки Travel Rule
3. Повернути відповідь DECLINED від сервісу Travel Rule
4. Перевірити логи processing-service та активність черг
5. Переконатися, що пошук транзакції продовжується після відхилення

Фактичний результат: Processing-service продовжує пошук та обробку транзакцій після відхилення перевірки Travel Rule.

Очікуваний результат: Processing-service повинен негайно припиняти пошук та подальшу обробку транзакцій після отримання статусу відхилення від Travel Rule.

Рекомендації:

• Негайно завершувати transaction-search після статусу DECLINED
• Додати early-stop механізм для processing pipeline
• Блокувати створення нових processing jobs після відмови Travel Rule
• Додати guard-check перед кожним етапом обробки транзакції
• Логувати причину зупинки processing flow
• Покрити сценарій integration та e2e тестами

Показати деталі

Відкрито

RPC

RPC-018 КРИТИЧНИЙ

Polygon RPC provider повертає некоректні block data

Polygon RPC провайдери (Infura, Alchemy, GetBlock) періодично повертають некоректні block payloads, які не проходять десеріалізацію через DeserError: BlockTransactions під час обробки блоків.

Polygon RPC EIP-4844

Оточення: Продакшн, Polygon RPC, Infura / GetBlock

Кроки відтворення:

1. Підключитися до Polygon RPC через Infura або Alchemy
2. Запросити block data через eth_getBlockByNumber
3. Спробувати десеріалізувати BlockTransactions
4. Перевірити появу періодичних DeserError

Фактичний результат: Десеріалізація блоків періодично завершується помилкою DeserError, через що RPC backend пропускає частину блоків.

Очікуваний результат: Block data повинні коректно десеріалізуватися, включаючи підтримку EIP-4844 blob transactions.

Рекомендації:

• Оновити логіку десеріалізації транзакцій для підтримки EIP-4844
• Додати fallback parsing для невідомих transaction variants
• Реалізувати retry та provider failover для некоректних RPC-відповідей
• Логувати номери проблемних блоків і відповіді провайдерів
• Валідувати RPC payload schema перед обробкою транзакцій
• Покрити blob transaction сценарії regression та integration тестами

Показати деталі

Відкрито

INV

INV-024 КРИТИЧНИЙ

Crypto invoice очікує повний timeout без виявленого депозиту

Crypto invoices залишаються у стані AwaitingCryptoDeposit до повного expires_at timeout (5-10+ годин), навіть якщо blockchain transaction так і не була виявлена, що створює поганий UX у payment widget.

Payments Crypto Invoices

Оточення: Продакшн, payment-invoices, crypto payment widget

Кроки відтворення:

1. Створити crypto invoice та відкрити payment widget
2. Перевірити стан AwaitingCryptoDeposit
3. Не надсилати crypto transaction
4. Дочекатися завершення deposit detection window
5. Переконатися, що invoice продовжує очікування до expires_at

Фактичний результат: Invoice залишається активним протягом усього timeout (5-10+ годин). Step_02 продовжує polling oracle-pool приблизно кожні 2 хвилини та отримує відповіді "Transaction still not found", тоді як widget продовжує показувати "awaiting payment".

Очікуваний результат: Invoices без виявлених blockchain transactions повинні завершуватися раніше після завершення deposit detection window, тоді як повний expires_at timeout повинен застосовуватися лише після виявлення транзакції.

Рекомендації:

• Реалізувати two-tier timeout логіку для crypto invoices
• Додати early expiry для invoices без знайдених транзакцій
• Зберігати можливість cancel під час deposit detection window
• Не завершувати invoice, якщо oracle-pool вже виявив in-flight transaction
• Відписувати oracle-pool listeners при будь-якому expiry state
• Винести invoice timeout values у configurable environment variables

Показати деталі

Відкрито

C2F

C2F-011 КРИТИЧНИЙ

GetInvoice повертає 500 після oracle-pool callback

Після отримання oracle-pool callback endpoint GetInvoice повертає 500 Internal Server Error замість коректного invoice object.

Payments Oracle Pool Invoices

Оточення: Development, payment-invoices, oracle-pool callback flow

Кроки відтворення:

1. Створити invoice через PaymentInvoicesService.CreateInvoice
2. Переконатися, що invoice має стан pending.awaiting_crypto_deposit
3. Викликати GetInvoice та перевірити, що endpoint працює до callback
4. Надіслати POST /v1/callbacks/oracle-pool зі status=1 та confirmations=1
5. Повторно викликати GetInvoice для того ж invoice_id

Фактичний результат: GetInvoice повертає 500 Internal Server Error після обробки oracle-pool callback.

Очікуваний результат: GetInvoice повинен повертати коректний invoice object з оновленим статусом: pending.awaiting_checks, pending.awaiting_exchange або expired.

Рекомендації:

• Перевірити invoice state transitions після oracle-pool callback
• Додати null та schema validation перед invoice serialization
• Логувати callback payloads та invoice state mutations для debugging
• Не допускати некоректні invoice states до GetInvoice response mapping
• Додати fallback error handling для malformed callback data
• Покрити callback-to-GetInvoice flow integration та regression тестами

Показати деталі

Підтверджено

AUTH

AUTH-042 ВИСОКИЙ

Токен сесії в URL

Токен аутентифікації видно в адресному рядку браузера, що дозволяє перехоплення через історію браузера або логи проксі.

Безпека OAuth Токен

Оточення: Всі браузери, після OAuth входу

Кроки відтворення:

1. Натиснути "Увійти через Google"
2. Завершити OAuth авторизацію
3. Перевірити URL після редіректу

Фактичний результат: Токен видно: site.com/home?token=abc123

Очікуваний результат: Токен зберігається тільки в httpOnly cookie

Рекомендації:

• Прибрати токен з URL параметрів
• Використовувати secure cookie з SameSite=Strict
• Перевірити логи доступу на наявність токенів

Показати деталі

Підтверджено

UI

UI-089 СЕРЕДНІЙ

Накладання меню на iPhone SE

Пункти меню навігації накладаються один на одного на екранах менше 375px

Інтерфейс Адаптивність Мобільна версія

Оточення: iOS Safari, iPhone SE (375×667)

Кроки відтворення:

1. Відкрити сайт на iPhone SE
2. Натиснути на меню-бургер
3. Подивитися розташування пунктів меню

Фактичний результат: Пункти меню накладаються, деякі недоступні

Очікуваний результат: Всі пункти меню видні та клікабельні

Рекомендації:

• Додати media query для екранів <375px
• Зменшити розмір шрифту або відступи
• Тестувати на реальному iPhone SE

Показати деталі

Підтверджено

SYNC

SYNC-014 ВИСОКИЙ

Втрата чернетки після оновлення сторінки

Останні зміни в довгій формі зникають, якщо користувач оновлює сторінку під час затримки автозбереження.

Втрата даних Автозбереження Safari

Оточення: Стейджинг, Safari 17, нестабільний Wi-Fi

Кроки відтворення:

1. Відкрити довгу форму з автозбереженням
2. Вводити дані 20-30 секунд
3. Оновити сторінку під час синхронізації

Фактичний результат: Останні зміни зникають без попередження

Очікуваний результат: Чернетка відновлюється або показується попередження про незбережені зміни

Рекомендації:

• Зберігати несинхронізований стан локально
• Додати індикатор стану синхронізації
• Попереджати перед перезавантаженням за наявності незбережених змін

Показати деталі

Відкрито

ROLE

ROLE-031 КРИТИЧНИЙ

Ескалація прав через кеш ролей

Після відкликання адмін-прав користувач ще певний час може виконувати захищені дії.

Оточення: Продакшн, SaaS адмін-панель

Кроки відтворення:

1. Зняти роль адміністратора з існуючого користувача
2. Не завершувати поточну сесію
3. Спробувати виконати адмін-дії

Фактичний результат: Частина адмін-ендпоінтів залишається доступною до протухання кешу

Очікуваний результат: Зміни ролей застосовуються одразу після оновлення прав

Рекомендації:

• Інвалідувати кеш ролей після оновлення прав
• Перевіряти ролі серверно для чутливих дій
• Логувати спроби доступу після revoke

Показати деталі

Підтверджено

AN

AN-022 СЕРЕДНІЙ

Подія покупки не потрапляє в аналітику

Успішне замовлення створюється, але подія покупки не відправляється після оформлення в один клік.

Аналітика GA4 Оформлення

Оточення: Продакшн, GA4 + внутрішній BI-конвеєр

Кроки відтворення:

1. Запустити оформлення в один клік зі збереженою карткою
2. Успішно завершити оплату
3. Перевірити мережеві запити й дашборд аналітики

Фактичний результат: Замовлення створене, але подія доходу відсутня

Очікуваний результат: Подія покупки відправляється один раз з коректною сумою та ID замовлення

Рекомендації:

• Запускати аналітику тільки після підтвердженого backend-успіху
• Додати сповіщення про просідання подій покупки
• Покрити checkout-сценарії окремим regression-набором

Показати деталі

Підтверджено

CHK

PERF-017 СЕРЕДНІЙ

Скидання фільтрів після пагінації каталогу

Після переходу на другу сторінку каталогу активні фільтри зникають, а список товарів змінюється без попередження.

Каталог Фільтри Досвід користувача

Оточення: Продакшн, Chrome 123, десктопний каталог

Кроки відтворення:

1. Відкрити каталог товарів
2. Застосувати 2-3 фільтри й сортування
3. Перейти на другу сторінку результатів

Фактичний результат: Фільтри скидаються, показуються невідфільтровані товари

Очікуваний результат: Фільтри зберігаються при пагінації

Рекомендації:

• Додати фільтри в URL параметри
• Використовувати History API для навігації
• Зберігати стан фільтрів в sessionStorage

Показати деталі

Відкрито

PDF

FILE-055 ВИСОКИЙ

PDF-рахунок доступний після виходу з акаунта

Посилання на інвойс продовжує відкривати документ навіть після завершення сесії користувача.

Безпека PDF Доступ

Оточення: Продакшн, клієнтський портал, історія інвойсів

Кроки відтворення:

1. Увійти в акаунт і відкрити історію рахунків
2. Скопіювати пряме посилання на PDF
3. Вийти з акаунта й відкрити посилання в новій вкладці

Фактичний результат: Документ завантажується без повторної перевірки доступу

Очікуваний результат: Доступ до файлу блокується або вимагає нову авторизацію

Рекомендації:

• Перевіряти авторизацію на рівні файлового ендпоінта
• Використовувати короткоживучі підписані URL
• Додати аудит доступу до чутливих документів

Показати деталі

Відкрито

SQL

SQL-008 КРИТИЧНИЙ

SQL-ін'єкція в пошуковому полі

Поле пошуку не екранує спецсимволи, дозволяючи виконання довільних SQL-запитів.

Безпека SQL-інʼєкція Пошук

Оточення: Продакшн, пошук товарів, PostgreSQL 14

Кроки відтворення:

1. Відкрити каталог товарів
2. Ввести в пошук: '; DROP TABLE orders; --
3. Натиснути Enter

Фактичний результат: Запит виконується без санітизації, можлива втрата даних

Очікуваний результат: Спецсимволи екрануються, пошук безпечний

Рекомендації:

• Використовувати параметризовані запити (prepared statements)
• Додати валідацію введення на рівні API
• Ввімкнути WAF правила для SQL-ін'єкцій

Показати деталі

Підтверджено

WARN

XSS-003 ВИСОКИЙ

XSS через поле відгуку

Відгуки користувачів відображаються без ескейпінгу HTML, дозволяючи виконання скриптів.

Безпека XSS Відгуки

Оточення: Продакшн, сторінка товару, розділ відгуків

Кроки відтворення:

1. Відкрити будь-який товар
2. Додати відгук з текстом: <script>alert('XSS')</script>
3. Зберегти відгук

Фактичний результат: Скрипт виконується при перегляді відгуку іншими користувачами

Очікуваний результат: HTML-теги ескейпляться, текст відображається як текст

Рекомендації:

• Використовувати textContent замість innerHTML
• Додати CSP заголовки
• Провести аудит всіх місць виводу користувацьких даних

Показати деталі

Підтверджено

TMO

RATE-007 СЕРЕДНІЙ

Відсутність обмеження частоти запитів на API

API-ендпоінт для зміни пароля не має обмежень на кількість запитів.

API Обмеження запитів Перебір

Оточення: Продакшн, API-ендпоінт /api/v1/password-reset

Кроки відтворення:

1. Відправити запит на зміну пароля
2. Повторити запит 100+ разів за хвилину
3. Перевірити відповіді сервера

Фактичний результат: Всі запити обробляються, можливий перебор токенів

Очікуваний результат: Після 5 невдалих спроб — тимчасове блокування

Рекомендації:

• Додати rate limiting (5 запитів на хвилину)
• Впровадити exponential backoff
• Логувати підозрілу активність

Показати деталі

Відкрито

EXP

UPLOAD-012 ВИСОКИЙ

Завантаження виконуваних файлів

Форма завантаження аватару приймає будь-які типи файлів включно з .exe та .php.

Безпека Завантаження файлів Валідація

Оточення: Продакшн, профіль користувача, завантаження аватару

Кроки відтворення:

1. Відкрити налаштування профілю
2. Вибрати файл shell.php замість зображення
3. Завантажити файл

Фактичний результат: Файл завантажується і доступний за прямим посиланням

Очікуваний результат: Помилка валідації — тільки зображення дозволені

Рекомендації:

• Валідувати MIME-тип і розширення файлу
• Перевіряти magic bytes файлу
• Зберігати файли поза web-root з перейменуванням

Показати деталі

Відкрито

PAY

PAY-014 КРИТИЧНИЙ

Повторне списання після повторної оплати

Якщо користувач повторно натискає оплату після довгої відповіді провайдера, створюються два успішні списання для одного замовлення.

Платежі Подвійне списання Checkout

Оточення: Продакшн, checkout, Stripe fallback flow

Кроки відтворення:

1. Оформити замовлення з банківською карткою
2. Дочекатися затримки відповіді платіжного провайдера
3. Повторно натиснути кнопку "Оплатити"

Фактичний результат: Створюються два успішні платежі та дубльований webhook

Очікуваний результат: Повторне натискання блокується, платіж обробляється один раз

Рекомендації:

• Додати idempotency key для кожного платіжного запиту
• Блокувати кнопку після першого кліку до відповіді провайдера
• Окремо логувати дубльовані webhooks і reconciliation case

Показати деталі

Підтверджено

BIL

PAY-029 СЕРЕДНІЙ

Некоректне округлення суми при частковій оплаті

При частковій оплаті з бонусами підсумкова сума в checkout відрізняється від суми, яка передається в платіжний провайдер.

Платежі Округлення Бонуси

Оточення: Продакшн, бонусний баланс, часткова оплата карткою

Кроки відтворення:

1. Додати товар з копійками до кошика
2. Застосувати бонусний баланс на частину суми
3. Перейти до підтвердження оплати карткою

Фактичний результат: На сторінці показано одну суму, а у провайдера формується інша

Очікуваний результат: Сума в UI, backend і провайдера повністю збігається

Рекомендації:

• Уніфікувати правила округлення між клієнтською і серверною частинами
• Працювати з мінімальними грошовими одиницями замість чисел з плаваючою комою
• Додати автотести для бонусних і змішаних оплат

Показати деталі

Підтверджено

AN

AN-031 ВИСОКИЙ

Подія повернення не потрапляє в аналітику

Після успішного refund в адмін-панелі подія повернення не потрапляє ні в GA4, ні у внутрішній фінансовий дашборд.

Аналітика Refund Фінанси

Оточення: Продакшн, адмін-панель, refund workflow

Кроки відтворення:

1. Відкрити оплачений order в адмін-панелі
2. Виконати часткове або повне повернення
3. Перевірити аналітичні події та BI-дашборд

Фактичний результат: Refund завершено, але подія про повернення не відправляється

Очікуваний результат: Аналітика оновлюється одразу після успішного refund

Рекомендації:

• Відправляти окрему refund event після підтвердження backend статусу
• Додати моніторинг розриву між orders і refunds в аналітиці
• Покрити refund flow окремим regression сценарієм

Показати деталі

Відкрито

UTM

AN-044 СЕРЕДНІЙ

Втрата UTM-міток після входу в акаунт

Після логіну користувача атрибуція кампанії скидається, і замовлення потрапляють у звітність як direct / none.

Аналітика UTM Атрибуція

Оточення: Продакшн, multi-step login перед checkout

Кроки відтворення:

1. Відкрити лендинг з UTM-мітками
2. Перейти до товару та увійти в акаунт
3. Завершити checkout і перевірити source / medium

Фактичний результат: Замовлення реєструється як direct / none без кампанії

Очікуваний результат: Початкові UTM-мітки зберігаються до завершення покупки

Рекомендації:

• Зберігати attribution state у sessionStorage або server session
• Не перезаписувати source після auth redirect
• Додати перевірки для login-to-checkout funnel

Показати деталі