payment gateway testing
Посібник тестувальника з тестування платіжного шлюзу:
Що таке платіжні процесори?
Відповідно до Вікіпедії, «Платіжний процесор - це компанія (часто третя сторона), призначена продавцем для обробки транзакцій з різних каналів, таких як кредитні картки та дебетові картки для банків-еквайрерів торговців. Процесор обробки платежів перевірятиме отримані дані, направляючи їх до банку-емітента відповідної картки або асоціації карток для перевірки, а також здійснюватиме низку заходів проти шахрайства проти трансакції '.
Деякі поширені платіжні шлюзи - Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments тощо.
В Інтернеті та в автономному режимі є багато літератури про платіжні шлюзи та відповідну термінологію.
У цьому підручнику я намагався спростити частину цієї інформації та спробував додати свій досвід.
Рекомендована література => Тестування додатків для інвестиційного банкінгу
Під час свого першого проекту я не знав, як правильно протестувати платіжний шлюз . Я поступово вчився і працював над успішним розгортанням інтеграцій PayPal, Braintree та Authorize.net з нашими додатками для електронної комерції.
Ми обговоримо загальну термінологію, зрозуміємо наскрізний потік транзакцій та корисні поради та найкращі практики.
Що ви дізнаєтесь:
- Термінологія платіжного шлюзу
- Різниця між платіжним шлюзом та платіжними процесорами
- Потік транзакції
- Чому нам потрібно тестувати платіжні шлюзи?
- Потрібні види тестування
- Корисні поради
- Контрольний список для тестування платіжного шлюзу та тестові випадки
- Налаштування пісочниці: Приклад платежів Брейнтрі
- Висновок
- Рекомендована література
Термінологія платіжного шлюзу
Давайте обговоримо деякі терміни, які ми будемо використовувати в цій статті:
1) Купець - Купець - це особа чи компанія, яка продає товари чи послуги. Flipkart, Amazon, eBay - деякі приклади торговців.
2) Кредитна картка - Пластикова картка, за допомогою якої можна купувати товари чи послуги через кредитний рахунок. Він має 16-значний номер картки, термін придатності, голограму, магнітну смужку, панель підпису та номер підтвердження картки (CVV).
Перед кредитною карткою:
Назад кредитної картки:
(Джерело: about.com)
3) Банк-еквайер - Банк-еквайер - це фінансова установа, яка веде банківський рахунок продавця і дозволяє продавцю приймати та обробляти дебетові та / або операції з кредитними картками у своєму магазині.
4) Банк-емітент - Банк-емітент - це фінансова установа, яка видає дебетову або кредитну картку клієнта. Кожного разу, коли клієнт використовує кредитну або дебетову картку для здійснення покупки, банк-емітент або схвалює, або відхиляє транзакцію на підставі статусу рахунку власника картки та передає цю інформацію Банку-еквайєру.
Наприклад, транзакція буде відхилена, якщо дата закінчення терміну дії картки неправильна, або якщо сума покупки перевищує ліміт кредитування на карті тощо.
5) Транзакція - Наскрізний процес, за допомогою якого торговець отримує кошти за операцію з клієнтом.
6) Авторизація - Авторизація вимагається, коли клієнт робить покупку. Ця авторизація надається банком-емітентом клієнта та підтверджує дійсність власника картки, платіжну здатність, наявність достатньої кількості коштів тощо. Після того, як це завершено, кошти утримуються, а залишок вираховується з кредитного ліміту клієнта, але не ще перераховані на торговий рахунок.
7) Захоплення - У цій дії продавець збирає відповідну інформацію про оплату клієнта та надсилає процесору запит на розрахунки / захоплення. Процесор використовує цю інформацію для ініціювання переказу коштів між картковим рахунком клієнта та банківським рахунком продавця.
Також читайте => Тестування банківських додатків
Різниця між платіжним шлюзом та платіжними процесорами
В Інтернеті доступно багато літератури про це і про те, чи є платіжний шлюз та процесор оплати окремими модулями з різними функціональними можливостями.
Протягом своїх проектів я спостерігав, що платіжний процесор та платіжні шлюзи використовуються як взаємозамінні без будь-якої фактичної різниці. Продавці зазвичай називають 'Платіжні шлюзи' платіжними процесорами, оскільки вони обробляють усі платежі.
'Платіжні процесори' вважають себе платіжними шлюзами, оскільки вони виступають як засіб для обробки та завершення безпечної платіжної транзакції.
Потік транзакції
Наступна діаграма підсумовує весь потік від моменту, коли клієнт розміщує замовлення, до замовлення, яке було успішним або відхиленим.
Якщо клієнт бажає скасувати замовлення, наступний потік:
Різниця між порожнечею та поверненням залежить від того, захоплена транзакція чи ні.
Незаплачений платіж може бути анульований, тобто кошти, що утримуються, повертаються на рахунок власників карток. Якщо транзакція вже врегульована або захоплена, тоді починається повернення коштів, що означає, що кошти беруться з торгового рахунку та повертаються назад на рахунок власника картки.
найкращі розробники ігор, для яких потрібно працювати
Чому нам потрібно тестувати платіжні шлюзи?
Якби ми хотіли робити покупки у справжньому магазині цегли та будівельних розчинів, ми б платили готівкою або провели свою картку (кредит або дебет) через автомат під час оформлення замовлення, щоб завершити транзакцію.
При використанні кредитних або дебетових карток POS ( Тестування пункту продажу ) машина вкаже, чи буде обробка платежу схвалена чи відхилена.
Подібним чином, під час онлайн-транзакцій нам потрібно мати подібну систему, яка негайно схвалює або відхиляє транзакцію.
З точки зору клієнта, обробка онлайн-платежів на веб-сайті електронної комерції повинна бути безперебійною. Клієнт натискає кнопку «Оплатити зараз» і має побачити повідомлення про успішний або відхилений платіж протягом наступних декількох секунд.
З точки зору магазину електронної комерції, продавець повинен переконатися, що повний цикл платежів (отримання транзакцій з Інтернет-магазину, захоплення та авторизація, повернення коштів, анулювання) працює нормально. Якщо будь-який з цих підкомпонентів працює не так, як очікувалося, тоді це може бути проблемою для продавця.
З точки зору продавця, фаза тестування дозволяє їм звикнути до обраного потоку процесора платежів та оцінити, чи обраний варіант насправді найкраще підходить для їхньої програми та бізнесу.
Потрібні види тестування
Залежно від вибору платіжного процесора та вимоги до продукту / програми, вам може знадобитися провести такі види тестування
- Функціональне тестування - Функціональне тестування потрібне для нових, менш усталених платіжних шлюзів, щоб гарантувати, що програма поводиться як слід, тобто вона обробляє замовлення, розрахунки, податки тощо, як саме передбачається. Для більш відомих платіжних процесорів подібне тестування може не знадобитися.
- Тестування інтеграції - Тестування інтеграції є критично важливим при інтеграції з платіжним шлюзом. Як тестувальник, вам потрібно буде перевірити, що інтеграція вашого веб-сайту / інтернет-магазину / програми працює нормально з обраними платіжними шлюзами. В якості тестера вам потрібно перевірити весь потік транзакцій:
- Зробити замовлення
- Перевірте, чи надходять кошти на рахунок продавця
- Переконайтеся, що транзакція може бути повернена або анульована успішно
- Тестування продуктивності - Важливо протестувати веб-сайт / Інтернет-магазин / додаток на ефективність. Процесор оплати не повинен зазнати збоїв, якщо кілька користувачів намагаються виконати транзакції одночасно.
- Тестування безпеки - Під час транзакції клієнт надаватиме конфіденційну інформацію, таку як номер кредитної картки, номер CVV тощо. Дуже важливо забезпечити передачу всієї конфіденційної інформації після шифрування та безпеку каналу.
Корисні поради
Виходячи з мого особистого досвіду, наведено кілька корисних порад для тестувальників:
# 1) Дослідіть, чи доступне безкоштовне середовище пісочниці (для ознайомчих та дослідницьких цілей) для Платіжного шлюзу, який потрібно протестувати або впровадити. Наявність пісочниці, безумовно, корисно і надає команді додаткову гнучкість для налаштування інструменту та тестування настільки глибоко, наскільки це потрібно.
# два) Переконайтеся, що транзакція перевірена наскрізь. У наших проектах ми протестували та повідомили про численні помилки, пов’язані із захопленням даних та потоком даних від програми до платіжного шлюзу. Деякі специфічні помилки:
- Інформація про ім’я клієнта (покупця) потрапляла неправильно
- Клієнт Дата закінчення терміну дії кредитної картки потрапляла неправильно через неправильну функцію, яка спричинила відхилення трансакцій банком-емітентом через неправильну інформацію про кредитну картку.
- Повторювана транзакція відображається в платіжному процесорі
# 3) Дослідіть обмеження пісочниць платіжного шлюзу.
Наприклад, Пісочниця Authorize.net підтримує одну валюту на пісочницю, тому, якщо вам потрібно протестувати кілька валют, вам потрібно буде налаштувати різні пісочниці. Крім того, ви ніколи не зможете перевірити, як поводитиметься система, коли обліковий запис Live Authorize.net обробляє мультивалютні транзакції.
# 4) Якщо оплата не вдається здійснити під час транзакції з будь-якої причини, клієнту слід показати відповідне повідомлення. Будь-яке повідомлення про помилку, яке є занадто технічним, наприклад „Об’єкт не встановлений для екземпляра“ або „Помилка 404“, може заплутати клієнта та вплинути на взаємодію з користувачем.
Також непогано показати загальне повідомлення на зразок „Здається, є певні проблеми в обробці транзакції, зв’яжіться з нами за номером 1-800-800-8000“.
# 5) З метою перевірки випуску після виготовлення клієнту (власникові бізнесу додатка) потрібно буде створити діючий обліковий запис процесора платежів, створити свій ідентифікатор продавця тощо.
Залежно від обраного платіжного процесора, налаштування рахунку може зайняти від 2 днів до кількох тижнів. Про це керівник проекту повинен повідомити клієнта заздалегідь із достатньо часу для створення реального рахунку до того, як програма та інтеграція процесора платежів почнуть працювати.
Контрольний список для тестування платіжного шлюзу та тестові випадки
Як і будь-яка інша програма, тестування платіжних процесорів передбачає належне планування тестування.
Наступний контрольний список може бути корисним для тестувальників і може бути використаний як довідковий:
1) Налаштуйте пісочницю процесора платежів.
два) Зберіть тестові номери кредитних карток, які будуть використовуватися для тестування різних кредитних карток. Як приклад, таку інформацію для платіжного процесора Braintree можна знайти в розділі платежів Braintree.
3) Перевірте поведінку програми, коли транзакція успішна.
4) Після успішної транзакції перевірте, чи повертається платіжний шлюз до вашої програми, щоб показати якесь повідомлення про успішну транзакцію / підтвердження.
5) Переконайтеся, що клієнт отримує якесь повідомлення про підтвердження транзакції, наприклад електронне повідомлення про підтвердження замовлення тощо, якщо транзакція успішна.
6) Перевірте, що відбувається, якщо платіж не вдається або платіжний процесор перестає реагувати - чи є повідомлення про помилку?
7) Перевірте поведінку програми за допомогою блокування спливаючих вікон браузера. Це може бути корисно, якщо у спливаючому вікні відображаються повідомлення про підтвердження.
8) Перевірте різні параметри запобігання шахрайству / безпеки.
Наприклад, якщо платіжна інформація клієнта не збігається з адресою, наданою банку-емітенту, будь-яке невідповідність призведе до відхилення транзакції.
9) Перевірте записи транзакцій у базі даних, якщо тестувальник має доступ до бази даних Програми.
10) Перевірте, що відбувається, коли закінчується сеанс клієнта.
одинадцять) Перевіряйте консоль протягом усієї транзакції та повідомляйте про будь-які помилки консолі, які спостерігаються.
12) Переконайтеся, що ця транзакція здійснюється на захищеному каналі.
Наприклад, сторінки оформлення замовлення можуть бути HTTPS порівняно з рештою веб-сайтів, які є сторінками HTTP.
13) Переконайтесь, що валюта процесора платежів налаштована правильно.
Наприклад, якщо додаток / веб-сайт є канадською компанією / роздрібною торгівлею, платіжний процесор повинен бути налаштований на прийняття валюти CAD.
14) Якщо додатки мають кілька варіантів оплати, як-от кредитна картка та PayPal разом, обидва варіанти оплати повинні бути індивідуально перевірені від кінця до кінця.
п'ятнадцять) Переконайтеся, що сума відшкодування або анулювання (з адміністраторського порталу процесора платежів) збігається з сумою транзакції. У жодному разі сума повернення / анулювання не повинна перевищувати суми операції.
Читайте також => Тестування роздрібної банківської системи
Налаштування пісочниці: Приклад платежів Брейнтрі
1) Перейдіть до Веб-сайт Брейнтрі .
два) Натисніть кнопку «Спробувати пісочницю».
(Примітка:Клацніть на будь-яке зображення, щоб збільшити його)
3) Ви будете перенаправлені на веб-сайт пісочниці Braintree. Заповніть всю необхідну інформацію та зареєструйтесь у пісочниці
деревоподібна структура даних c ++
4) Ви отримаєте повідомлення електронною поштою на електронну адресу, вказану під час реєстрації, щодо підтвердження створення облікового запису
5) Вам потрібно заповнити форму інформації про користувача для подальшої обробки місця, де вам потрібно буде вибрати пароль. Натисніть кнопку «Прийняти та створити свій рахунок»
6) Ви увійдете в систему та перенаправите на портал адміністратора Braintree
7) Зверніть увагу на клавіші пісочниці та використовуйте їх у своєму додатку для інтеграції з цією пісочницею Брейнтрі.
8) Після завершення інтеграції пісочниця готова до використання. Якщо вам потрібно оновити налаштування пісочниці, ви можете це зробити за допомогою меню налаштувань.
Часто використовуваний параметр меню налаштувань:
Висновок
Процесор оплати - це дуже важливий компонент для будь-якої програми електронної комерції, яка призначена для прийому платежів від своїх клієнтів. Тому важливо ретельно протестувати цей компонент. Будь-який пропущений сценарій може вплинути на продажі / транзакції продавця та негативно вплинути на взаємодію з клієнтом або покупцем.
Тестери повинні підготувати або налаштувати тестове середовище (пісочниці, зібрати фіктивну інформацію про кредитну картку, коди відповідей тощо) та сформулювати стратегію тестування - як для тестового середовища, так і для тестування на випуск / після випуску.
Про автор: Ця корисна стаття написана Нехою. В даний час вона працює менеджером із забезпечення якості та спеціалізується на керівництві внутрішніми та офшорними командами з контролю якості та управління ними.
Маєте запитання або хочете поділитися своїм досвідом із тестування шлюзу платежів? Повідомте нас у коментарях нижче.
Рекомендована література
- Альфа-тестування та бета-тестування (повний посібник)
- Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
- Функціональне тестування проти нефункціонального тестування
- Ідеальне керівництво щодо резюме тестування програмного забезпечення (із зразком резюме тестувальника програмного забезпечення)
- Повне керівництво з тестування перевірки складання (тестування BVT)
- Посібник для початківців для тестування SalesForce
- Тестування Праймера Завантажити електронну книгу
- 68 основних ресурсів, щоб бути успішним випробувачем (не пропустіть!)