Тестування платіжного шлюзу (Payment Gateway)
Last updated
Last updated
Платіжний шлюз – це сервіс, який допомагає нам здійснювати грошову транзакцію в Інтернеті, він приймає кредитні картки, дебетові картки, інтернет-банкінг та інші способи оплати від клієнта до виконання транзакції. Служби платіжних шлюзів шифрують конфіденційну інформацію, таку як номери карт, CVV, паролі, пін-коди тощо. Вони інтегровані з платформами електронної комерції для здійснення та отримання платежів. Зі збільшенням цифрових платежів на платформах електронної комерції ми повинні надавати клієнтам безпечні та зручні платіжні шлюзи, які можуть витримувати високі навантаження без будь-яких збоїв у роботі. Деякими з найпоширеніших прикладів платіжних шлюзів є Paypal, Paytm, Razor pay, Instamojo і т.д.
Термінологія :
Торговець (Merchant): це особа чи компанія, які продають товар чи послугу, вони можуть бути постачальником послуг, продавцем товару, магазином електронної комерції тощо. Вони приймають онлайн-платежі для свого бізнесу;
Банк-еквайєр (Acquiring bank): це банк продавця, коли клієнт платить через платіжний шлюз, сума зараховується до банк-еквайєра;
Банк-емітент (Issuing bank): це банк клієнта, коли продавець отримує платіж, сума віднімається з банку-емітента;
Транзакція: це платіж, зроблений у касі платіжного шлюзу. Він створює унікальний ідентифікатор, який називається ідентифікатором транзакції;
Авторизація: платіжний шлюз надсилає запити авторизації на рахунок клієнта (банк-емітент) для вирахування суми. Запит авторизації може бути відхилений або схвалений банком-емітентом;
Аутентифікація - це метод, за допомогою якого банк перевіряє особу клієнта, що здійснює платіж, це може бути CVV, OTP, PIN-код, пароль тощо.
Потік транзакцій платіжного шлюзу
Клієнт вибирає товар чи послугу та отримує сторінку оплати;
Він вводить дані своєї карти, такі як номер, CVV, термін дії тощо. Ця інформація надійно передається платіжному шлюзу;
Платіжний шлюз шифрує дані картки та виконує перевірку на шахрайство, перш ніж надіслати дані до банку-еквайєра;
Банк-еквайєр надійно відправляє інформацію до схем карт, виконує ще одну перевірку на шахрайство і відправляє її в банк-емітент;
Банк-емітент проводить ще одну перевірку на шахрайство та авторизує транзакцію. Повідомлення про схвалення/відхилення надсилається Еквайреру через карткові схеми;
Платіжний шлюз отримує повідомлення про прийняття/відхилення, яке передає повідомлення продавцю. Якщо платіж схвалено, Еквайрер отримує платіж від банку-емітента та вносить кошти на рахунок продавця.
Попередні умови (prerequisites) для тестування платіжного шлюзу
Зберіть тестові дані для тестових дебетової/кредитної картки;
Зберіть інформацію, пов'язану з типом платіжного шлюзу, який ми маємо намір протестувати;
Визначте параметри тестування продуктивності;
Зберіть інформацію про коди помилок, які можуть виникнути у платіжному шлюзі, щоб ми знали, чи виникла помилка з нашого боку, чи вона пов'язана з платіжним шлюзом;
Налаштуйте середовище Sandbox для перевірки платіжних систем без фактичної оплати.
Види тестування платіжного шлюзу
Functional Testing : ми проводимо функціональне тестування для нових чи непопулярних систем. Це життєво важливо, оскільки гарантує, що система повністю функціональна та її функції працюють належним чином. Це допомагає перевірити як додаток, і шлюз;
Security testing : гарантує, що платіжний шлюз захищає дані, які він обробляє під час оплати. Він захищає систему від кібератак, хакерів та інших уразливостей безпеки. Ми повинні переконатися, що ми дбаємо про конфіденційну інформацію, надану клієнтом;
Performance testing : гарантує, що програма не вийде з ладу, якщо велика кількість користувачів відправлять платіж одночасно. Цей тип тестування має вирішальне значення, особливо під час великих розпродажів чи святкових сезонів;
Integration testing : зазвичай платформа електронної комерції або будь-який інший додаток, що вимагає оплати, потребує інтегрованого в систему платіжного шлюзу. Інтеграційне тестування гарантує, що платіжний шлюз легко інтегрується із веб-сайтом продавця. Тут перевіряємо розміщення замовлення, обробку платежів, підтвердження замовлення, тобто. повний потік транзакцій.
Приклади тест-кейсів :
Functional :
Кожен варіант оплати можна вибрати, текстові поля можна друкувати;
Збережена кредитна/дебетова картка доступна на сторінці оплати;
Можна встановити стандартну карту;
Клієнт отримує відповідне повідомлення електронною поштою та текст після успішного/невдалого платежу;
Платіжний шлюз перенаправляє назад у додаток після завершення платежу;
Правильно розраховуються сума, податки, знижки, кредити магазину тощо;
Система змінює формат валюти та мови на запит користувача;
Платіж не проходить, якщо якесь обов'язкове поле порожнє;
Поведінка системи при відключенні Інтернету під час оплати;
Поведінка системи якщо сесія закінчується;
Перевірка подвійної оплати;
Перевірка різних комбінацій дійсних та недійсних даних для номера картки + терміну дії + CVV;
Перевірка працездатності за наявності розширень браузера, наприклад, блокувальників реклами;
Кожен варіант оплати спрямовується у відповідний потік платежів (payment flow).
Performance :
Працездатність платіжного шлюзу, коли кілька користувачів одночасно намагаються здійснити транзакцію;
Чи швидко реагує процесор;
Чи відповідає час, необхідний для того, щоб додаток досяг платіжного шлюзу, вимогам;
Чи зарахована та сама сума клієнту під час повернення, а також перевірте терміни повернення відповідно до положень та умов;
Чи оновлюються деталі транзакції у базі даних у правильному форматі.
UI :
labels та boxes видно;
Номер карти маскується астерисками під час введення;
Логотип/назва підприємства платіжного шлюзу видно;
Усі варіанти оплати видно;
Колірна схема відповідає специфікаціям;
Правильні повідомлення відображаються під час успішного/невдалого платежу;
Розділи промокоду, подарункова карта, купон видно;
Усі помилки або помилки користувача виділено червоним кольором.
Security :
Реквізити картки маскуються;
Конфіденційна інформація шифрується;
Додаток захищений від міжсайтового скриптингу, спуфінгу тощо;
Онлайн-транзакція відбувається на безпечному каналі, такому як HTTPS;
Перевірте всі настройки запобігання шахрайству/безпеці програми.
Клієнт отримує одноразовий код (OTP) під час ініціювання транзакції зі своїх банківських реквізитів;
Також перевірте той самий сценарій з кількома картами, прив'язаними до різних телефонних номерів одного облікового запису.
Джерела:
Дод. матеріал: