Тестові випадки платіжних шлюзів: типи та контрольний список
Томас Гамільтон
⚡ Розумний підсумок
Тестування платіжних шлюзів перевіряє, чи кожна онлайн-транзакція обробляється безпечно, точно та швидко. На цій сторінці пояснюються типи шлюзів, методи тестування, контрольний список підготовки та двадцять один готовий до використання сценарій тестування, які команди з контролю якості застосовують до процесів оформлення замовлення в реальному часі.
Тестування платіжного шлюзу
Тестування платіжного шлюзу це тестування Payment Gateway в системі онлайн-покупок і транзакцій користувачами. Метою тестування платіжного шлюзу є забезпечення безпеки, надійності та продуктивності платіжного шлюзу шляхом шифрування та захисту платіжних реквізитів між користувачем і продавцем, забезпечуючи безперебійну роботу з оплатою.
Система платіжного шлюзу – це служба додатків електронної комерції який підтверджує оплату кредитною карткою для онлайн-покупок. Платіжні шлюзи захищають дані кредитної картки, шифруючи конфіденційну інформацію, як-от номери кредитних карток, дані власника рахунку тощо. Ця інформація безпечно передається між клієнтом і продавцем і навпаки. Сучасні платіжні шлюзи також безпечно підтверджують платежі за допомогою дебетових карток, електронних банківських переказів, готівкових карток, бонусних балів тощо.
Оскільки шлюз розташований між покупцем, продавцем і банком, один його недолік негайно зупиняє отримання доходу.
Безкоштовно приєднуйтеся до нашого проекту з тестування платіжного шлюзу
Типи системи платіжних шлюзів
Шлюзи відрізняються тим, де покупець вводить дані картки, як показано нижче.
Розміщений платіжний шлюз
Розміщена система платіжного шлюзу спрямовує клієнта з сайту електронної комерції на посилання на шлюз під час процесу оплати. Після здійснення платежу клієнт повертається на сайт електронної комерції. Для такого типу платежу вам не потрібен ідентифікатор продавця, прикладом розміщеного платіжного шлюзу є PayPal, Noche і WorldPay.
Спільний платіжний шлюз
У спільному платіжному шлюзі під час обробки платежу клієнт спрямовується на сторінку платежу та залишається на сайті електронної комерції. Після заповнення реквізитів платежу процес платежу продовжується. Оскільки він не залишає сайт електронної комерції під час обробки платежу, цей режим є простим і кращим, прикладом спільного платіжного шлюзу є eWay, Stripe.
Існують також варіанти шлюзів із власним хостингом, хостингом через API та мобільними гаманцями.
Чому важливо тестувати платіжні шлюзи
Сторінка оформлення замовлення – це останній крок між покупцем і доходом, тому будь-який дефект на ній коштує грошей з моменту його появи. Систематичне тестування захищає цей крок, виявляючи проблеми ще до того, як клієнти з ними зіткнуться.
- Захищає дохід: Невдала або повільна транзакція змушує покупців покинути кошик, а покинуті кошики рідко повертаються.
- Зміцнює довіру: Замасковані поля картки, зашифрований трафік та чіткі повідомлення з підтвердженням запевняють покупців, що їхні гроші обробляються належним чином.
- Запобігає збиткам від шахрайства: Перевірка правил CVV, адреси та швидкості доставки запобігає шахрайським замовленням до відправлення товарів.
- Забезпечує відповідність продавця вимогам: Карткові схеми вимагають надійної автентифікації клієнтів, а тестування є доказом того, що ці засоби контролю працюють.
- Зменшує витрати на підтримку: Дубльовані платежі, відсутні квитанції та затримки повернення коштів призводять до дорогих штрафів та повернення коштів.
- Виявляє дефекти на ранній стадії: Виправлення помилки інтеграції в пісочниці коштує лише частку від її виправлення після збою у виробництві.
Ці переваги залежать від правильного поєднання типів тестів, що описано далі.
Тестування типів для платіжного домену
Тестування для Payment Gateway повинно включати
Функціональне тестування: Це акт тестування базової функціональності платіжного шлюзу. Потрібно перевірити, чи програма працює так само, як це має бути, як обробка замовлень, обчислення, додавання ПДВ відповідно до країни тощо.
інтеграцією: Перевірте інтеграцію зі службою кредитної картки.
продуктивність: визначте різні показники продуктивності, як-от найбільшу можливу кількість користувачів, які проходять через шлюзи протягом певного дня, і перетворення їх на одночасних користувачів
Безпека: Вам потрібно виконати глибоку перевірку безпеки для Payment Gateway.
додавати тестування локалізації для валюти та мови, тестування на сумісність для пристроїв, і регресійне тестування після кожного оновлення API постачальника.
Як перевірити платіжний шлюз: повний контрольний список
Перш ніж почати тестування –
- Зберіть належні тестові дані для фіктивного номера кредитної картки для maestro, visa, master тощо.
- Збирайте інформацію про платіжний шлюз, таку як Google Гаманець, Paypal або щось інше
- Зберіть документ платіжного шлюзу з кодами помилок
- Зрозумійте сеанс і параметри, передані через додаток і платіжний шлюз
- Зрозумійте та перевірте обсяг пов’язаної інформації, що передається через рядок запиту, змінну або сеанс
- Разом із мовою платіжного шлюзу перевірте мову програми
- Відповідно до різних налаштувань платіжного шлюзу, як-от формат валюти, дані про підписку збираються.
Порада: Зіставте кожну очікувану помилку із задокументованим кодом помилки постачальника, щоб нечіткий дефект «платіж не пройшов» став відтворюваним запитом.
Як налаштувати тестове середовище платіжного шлюзу
Надійні результати починаються з середовища, яке поводиться як продакшн, без переміщення реальних грошей. Майже кожен постачальник постачає пісочницю, яка відображає живий API, але нічого не врегульовує, і саме в цій пісочниці проводиться більшість тестів платіжних шлюзів.
- Запит облікових даних для ізольованого середовища. Отримайте окремий ідентифікатор продавця, ключ API та секретний код і зберігайте їх поза межами репозиторію вихідного коду.
- Спрямуйте програму на кінцеву точку ізольованого середовища. Підтвердіть у мережевому журналі, що до хоста активного шлюзу не надходить жодного запиту.
- Завантажте офіційні тестові картки. Кожна схема публікує цифри, які примушують до фіксованого результату: схвалення, відхилення, недостатньо коштів, термін дії картки закінчився або картка була заблокована.
- Ніколи не копіюйте виробничі дані. Рада стандартів безпеки PCI Правила забороняють використання даних власників карток у реальному часі в тестових середовищах, тому маскуйте кожен запис.
- Увімкнути тестовий режим 3D Secure. Запустіть безперешкодний потік та потік викликів, щоб використати шляхи перенаправлення, тайм-ауту та скасування.
- Зареєструйте приймач вебхука. Статус платежу часто надходить асинхронно, тому переконайтеся, що сповіщення про фіксацію, повернення коштів та повернення коштів оновлюють запис замовлення.
- Моделювання несправностей мережі. Відкидати або затримувати відповіді через проксі-сервер і перевіряти відсутність дублікатів платежів, коли покупець намагається повторити покупку.
- Скидання стану між запусками. Очистіть кошики, сесії та збережені токени, щоб застаріла сесія не маскувала дефект.
Ведіть короткий список дій (runbook) для пісочниці URLs, номери тестових карток та очікувані коди відповідей. Це дозволяє новим тестувальникам негайно відтворити будь-який сценарій і водночас служить аудиторським доказом.
Увага! Ніколи не спрямовуйте тестовий набір на реальні облікові дані. Одна випадкова авторизація на реальній картці є як фінансовим інцидентом, так і порушенням нормативних вимог.
Приклад тестових випадків платіжного шлюзу
Нижче наведено важливі тестові сценарії/випадки для перевірки платіжного шлюзу
| Sr# | Тестові випадки |
|---|---|
| 1 | Під час процесу оплати спробуйте змінити мову платіжного шлюзу |
| 2 | Після успішної оплати перевірте всі необхідні компоненти, незалежно від того, витягнуто чи ні |
| 3 | Перевірте, що станеться, якщо платіжний шлюз перестане відповідати під час оплати |
| 4 | Під час процесу оплати перевірте, що станеться, якщо сесія закінчиться |
| 5 | Під час процесу оплати перевірте, що відбувається на сервері |
| 6 | Перевірте, що станеться, якщо процес оплати не вдасться |
| 7 | Перевірте записи бази даних, чи зберігаються вони дані кредитної картки чи ні |
| 8 | Під час процесу оплати перевірте сторінки помилок і сторінки безпеки |
| 9 | Перевірте налаштування блокувальника спливаючих вікон і подивіться, що станеться, якщо блокувальник спливаючих вікон увімкнути або вимкнути |
| 10 | Між платіжним шлюзом і буферними сторінками програми |
| 11 | Перевірка успішного платежу, код успіху надсилається до програми та відображається сторінка підтвердження |
| 12 | Перевірте, чи транзакція обробляється негайно, чи обробку здійснює ваш банк |
| 13 | Після успішної транзакції перевірте, чи повертається платіжний шлюз до вашої програми |
| 14 | Перевірте всі формати та повідомлення після успішного процесу оплати |
| 15 | Якщо ви не маєте квитанції авторизації від платіжного шлюзу, товар не слід відправляти |
| 16 | Повідомляйте власника про будь-які трансакції, оброблені електронною поштою. Зашифрувати вміст пошти |
| 17 | Звірте формат суми з форматом валюти |
| 18 | Перевірте, чи можна вибрати кожен із варіантів оплати |
| 19 | Перевірте, чи кожен із перерахованих варіантів оплати відкриває відповідний варіант оплати відповідно до специфікації |
| 20 | Перевірте, чи платіжний шлюз за замовчуванням використовує потрібний варіант дебетової/кредитної картки |
| 21 | Переконайтеся, що параметр за умовчанням для дебетової картки показує спадне меню вибору картки |
Наступне рішення полягає в тому, який із цих сценаріїв заслуговує на сценарій.
Ручне та автоматизоване тестування платіжних шлюзів
Обидва підходи належать до платіжної програми, і корисне питання полягає в тому, які випадки підходять для якого методу. Ручна робота найсильніша для нових інтеграцій та всього, що потребує людської оцінки. Автоматизація заробляє собі на життя стабільними, повторюваними шляхами, які мають проходити під час кожної збірки.
| Аспект | Ручне тестування | Автоматичне тестування |
|---|---|---|
| Найкраще підходить для | Дослідницькі перевірки, перші інтеграції, візуальний огляд та перевірка формулювань | Регресійні пакети та перевірки «smoke checks» для кожного розгортання |
| швидкість | Повільно; один тестер запускає один сценарій за раз | Швидко; багато сценаріїв виконуються паралельно |
| Профіль витрат | Низькі зусилля налаштування, високі повторювані зусилля | Високі зусилля налаштування, низькі повторні зусилля |
| Типова оснастка | Інструменти розробника браузера та панелі інструментів «пісочниці» | Selenium, Appium, Postman для перевірок API |
| Основна слабкість | Важко масштабувати для багатьох типів карток або рівнів навантаження | Не звертаючи уваги на проблеми макетування та зручності використання |
Практичний поділ полягає в автоматизації шляхів успішного, відхилення та повернення коштів для кожного типу картки та резервуванні ручних сеансів для нових версій шлюзів. Керуйте профілями навантаження окремо за допомогою JMeter.
На що слід звернути увагу, перш ніж купувати пакет Gateway
- Якщо ви купили магазинping пакет кошика, дізнайтеся про його сумісність
- Якщо магазинping термін подання пакета шлюзу, зверніться до постачальника платіжного шлюзу за списком підтримуваних програм
- Шлюз повинен забезпечувати захист системи перевірки адреси
- Дізнайтеся пропоновані типи захисту транзакцій
- Перевірте, які типи дебетових чи кредитних карток приймає вибраний платіжний шлюз
- Перевірте комісію за транзакцію, яку стягує платіжний шлюз
- Перевірте, чи шлюзи отримують оплату безпосередньо у формі, чи направляють на іншу сторінку для завершення покупки
