Найпоширеніші проблеми в тестуванні платежів 💳

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

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

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

У цій статті, я хочу розглянути найпоширеніші проблеми, які можуть виникнути під час тестування платежів та коротко познайомити вас з ними.
Поїхали! 🏃🏼‍♀️

Що таке PSP (Payment Service Provider)?

PSP (Payment Service Provider) — це third-party service, який дозволяє приймати електронні платежі та є посередником між тими хто здійснює платежі (consumers) і тими хто їх приймає (retailers).

PSP поділяється за типами флоу та типами акаунтів.

🎢 Типи флоу:

В залежності від того, як саме відбувається платіжна взаємодія між користувачем і PSP, існує два основні флоу:

1. Redirect Flow.

• Користувач перенаправляється на сторінку PSP для завершення оплати.
• Вводить дані картки на цій сторінці.
• Після підтвердження транзакції його повертають на сайт продавця.

✅ Плюси: менше відповідальності за безпеку даних на боці продавця.

❌ Мінуси: можливий відтік клієнтів через перехід на сторонній ресурс.

2. H2H (Host-to-Host) Flow.

• Платіжні дані передаються безпосередньо з сайту продавця на сервер PSP через API.
• Весь процес відбувається у фоновому режимі і користувач не бачить процесу переказу коштів.

✅ Плюси: повний контроль UX, плавність процесу.

❌ Мінуси: вища відповідальність за безпеку.

👤 Типи акаунтів:

PSP можуть підтримувати різні типи акаунтів. Основні з них:

1. Банківські картки.

• Найпоширеніший метод: Visa, MasterCard, American Express тощо.
• Підтримка 3D Secure, захист від шахрайства, миттєві транзакції.

2. Криптовалюти.

• Оплата через криптогаманці Bitcoin, Ethereum та ін.
• Оплата через криптовалютних провайдерів.

3. Платіжні термінали.

• Актуально для локальних платежів (наприклад, через IBox, EasyPay).
• Користувач отримує квитанцію або код для оплати в терміналі.

4. Альтернативні методи.

• E-wallets: Google Pay, Apple Pay, PayPal.
• Прямі банківські перекази: через IBAN або платіжні сервіси (SEPA, SWIFT).

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

1. Подвійне списання коштів (Double charge).

Таке трапляється коли користувач, наприклад, натискає кнопку «Оплатити» двічі (через повільний інтернет або фріз у браузері), і з його картки списуються гроші двічі.

🔍 Можлива причина: Відсутній захист від повторного запиту, погано реалізована обробка транзакцій на бекенді.

2. Невірна сума списання.

Користувач вводить 100 грн, а система списує 1000 грн або взагалі іншу суму.

🔍 Можлива причина: Помилки округлення, некоректна конвертація валют, неправильна передача суми в API.

3. Недостатня валідація платіжних даних.

Це коли система приймає неіснуючі або некоректні карткові номери (наприклад: 1234567890123456).

🔍 Можлива причина: Відсутня або слабка реалізація валідації.

4. Некоректна обробка статусів платежу.

Дуже поширена проблема і трапляється коли платіж пройшов, але статус на UI показує «Unsuccess» або «Pending» і навпаки.

🔍 Можлива причина: Відсутність коректного мапінгу статусів з API, несинхронна обробка запитів, погана логіка релоадів/колбеків.

5. Відсутність або помилки в поверненні коштів (Refund).

Це трапляється коли користувач не може отримати повернення коштів, або повернення працює некоректно (часткове, подвоєне тощо).

🔍 Можлива причина: Погано протестований процес рефанда, помилки в логіці обліку транзакцій.

6. Валютні баги.

Може бути таке, що користувач обирає оплату в EUR, а система списує USD або некоректно розраховує конверсію.

🔍 Можлива причина: Невірна логіка вибору валюти, проблеми з курсами валют або таймінгом запиту до сервера.

7. Відсутність тестового середовища.

Доволі часто трапляється що провайдер не має/ не надає sandbox-у і розробники/ тестувальники тестують на продакшині, що призводить до реального списання коштів.
Компанія звісно що не хоче втрачати гроші і робить тестування дуже обмеженим.
Як наслідок платіжка не протестована на всі можливі/ найпоширеніші сценарії і ми ризикуємо мати багато багів після відкриття платіжки для реальних юзерів.

🔍 Можлива причина: Відсутність sandbox-режиму або тестових карток.

8. UI/UX баги.

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

🔍 Можлива причина: Недостатнє опрацювання сценаріїв UI.

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

‼️ Адже помилки в оплаті — це не просто баги. Це — втрата довіри до компанії ‼️

Я сподіваюсь ця невеличка стаття допоможе Вам в момент коли Ви стикнетесь з тестуванням платіжок на новому проєкті або коли просто почуєте: «А тепер давайте заімплементуємо платіжку!».

Дякую за те, що прочитали, а також закликаю вас ділитись своїми кейсами у коментарях!👇🏼

Щиро Ваша, Mother of QA!❤️