Перевод статьи Neha «Payment Gateway Testing: The Tester’s Hands-on Guide with Checklist».
Руководство тестировщика по тестированию платежных шлюзов:
Что такое платежные системы?
Согласно Википедии, “Платежная система – это компания (часто сторонняя), назначенная продавцом для обработки транзакций по различным каналам, таким как кредитные и дебетовые карты для банков-эквайеров. Платежная система проверяет полученные данные, отправляя их в банк-эмитент соответствующей карты или ассоциацию пластиковых карт для проверки, а также принимает ряд мер по борьбе с мошенничеством в отношении транзакции”.
БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"
К наиболее распространенным платежным шлюзам относятся: Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments и т.д.
В Интернете и за его пределами имеется много информации о платежных шлюзах и связанной с ними терминологии.
В этом руководстве я попытался изложить эту информацию доступным языком и добавил свой опыт.
Во время своего первого проекта я понятия не имел о том, как правильно тестировать платежный шлюз. Я постепенно учился и работал над успешным внедрением интеграции PayPal, Braintree и Authorize.net с нашими приложениями электронной коммерции.
Ниже мы обсудим общепринятую терминологию, разберем полный поток транзакций, а также полезные советы и лучшие практики.
Содержание
Разница между платежным шлюзом и платежной системой
Зачем нужно тестировать платежные шлюзы?
Чек-лист и тест-кейсы для тестирования платежных шлюзов
Терминология платежных шлюзов
Давайте обсудим некоторые термины, которые мы будем использовать в этой статье:
1. Торговый субъект – это человек или компания, которые продают товары или услуги. В качестве примеров можно привести Flipkart, Amazon, eBay.
2. Кредитная карта – пластиковая карта, которая может быть использована для покупки товаров или услуг через кредитный счет. Она имеет 16-значный номер, срок действия, голограмму, магнитную полосу, панель для подписи и номер CVV (Card verification value).
Лицевая сторона кредитной карты:
Обратная сторона кредитной карты:
3. Банк-эквайер – это финансовое учреждение, которое обслуживает банковский счет продавца. Оно позволяет продавцу принимать и обрабатывать транзакции по дебетовым и/или кредитным картам в своем магазине.
4. Банк-эмитент – это финансовое учреждение, которое выпускает дебетовую или кредитную карту клиента. Всякий раз, когда клиент использует кредитную или дебетовую карту для совершения покупки, банк-эмитент либо одобряет, либо отклоняет транзакцию на основании состояния счета держателя карты и передает эту информацию банку-эквайеру.
Например, транзакция будет отклонена, если срок действия карты неверен или если сумма покупки превышает кредитный лимит карты и т.д.
5. Транзакция – сквозной процесс, в ходе которого торговый субъект получает средства для проведения сделки с клиентом.
6. Авторизация – запрашивается, когда клиент совершает покупку. Это разрешение предоставляется банком-эмитентом клиента и подтверждает действительность держателя карты, его платежеспособность, наличие достаточных средств на счете и т. д. После авторизации средства удерживаются, а остаток вычитается из кредитного лимита клиента, но еще не переводится на счет торгового субъекта.
7. Фиксация – в ходе этого действия торговый субъект собирает важную платежную информацию клиента и отправляет запрос на расчет/фиксацию платёжной системе. Система использует эту информацию для инициирования перевода средств между карточным счетом клиента и банковским счетом торгового субъекта.
Разница между платежным шлюзом и платежными системами
В Интернете встречается много размышлений о том, являются ли платежный шлюз и платежная система отдельными модулями с разными функциональными возможностями.
В ходе работы над своими проектами я заметил, что платежные системы и платежные шлюзы используются как взаимозаменяемые понятия без какого-либо фактического различия. Торговые субъекты обычно относят платежные шлюзы к системам, поскольку они обрабатывают все платежи.
“Платежные системы” считают себя платежными шлюзами, поскольку они выступают в качестве средства для обработки и совершения безопасной платежной сделки.
Выполнение транзакции
На следующей блок-схеме представлен весь процесс транзакции с момента размещения заказа клиентом до успешного выполнения или отклонения.
Если клиент хочет отменить заказ, порядок действий будет следующий:
Разница между аннулированием и возвратом средств зависит от того, зафиксирована транзакция или нет.
Незавершенный платеж может быть аннулирован, что означает, что удержанные средства зачисляются обратно на счет владельца карты. Если транзакция уже проведена или зафиксирована, то инициируется возврат, то есть средства снимаются со счета торгового субъекта и зачисляются обратно на счет держателя карты.
Зачем нужно тестировать платежные шлюзы?
Когда мы делаем покупки в реальном обычном магазине, мы платим наличными или проводим нашу карту (кредитную или дебетовую) через платежный терминал во время оформления заказа, чтобы завершить транзакцию.
Если мы используем кредитные или дебетовые карты, POS (Point of Sale testing) терминал сообщит, одобрен платеж или отклонен.
Аналогичным образом, во время онлайн-транзакций нам необходимо иметь подобную систему, которая мгновенно одобряет или отклоняет транзакцию.
С точки зрения покупателя обработка онлайн-платежа на сайте электронной коммерции должна быть беспрепятственной. Клиент нажимает кнопку “Оплатить сейчас” и в течение нескольких секунд он хочет увидеть сообщение об успешно проведенном или же отклоненном платеже.
С точки зрения онлайн-магазина торговому субъекту необходимо убедиться, что полный цикл оплаты (получение транзакций из интернет-магазина, фиксация и авторизация, возврат средств, аннулирование) работает нормально. Если какой-либо из этих компонентов функционирует не так, как ожидается, то это может стать для него серьезной проблемой.
Если говорить о продавцах, этап тестирования позволяет им привыкнуть к выбранной системе обработки платежей и оценить, действительно ли выбранный вариант наилучшим образом подходит для их приложения и бизнеса.
Виды тестирования
В зависимости от выбора платежной системы и требований к продукту/приложению вам может потребоваться провести следующие виды тестирования:
- Функциональное тестирование – требуется для новых, менее известных платежных шлюзов. Оно необходимо, чтобы убедиться, что приложение ведет себя так, как должно, т.е. обрабатывает заказы, расчеты, налоги и т.п. именно так, как и предполагается. Для более известных платежных систем такое тестирование может и не потребоваться.
- Интеграционное тестирование – имеет решающее значение при интеграции с платежным шлюзом. Как тестировщик вы должны убедиться, что интеграция вашего сайта/онлайн-магазина/приложения работает нормально с выбранными платежными шлюзами. Вам необходимо проверить весь поток транзакций:
- разместить онлайн-заказ;
- проверить, поступили ли средства на счет торгового субъекта;
- проверить успешность возврата средств в транзакции или её аннулирования.
- Тестирование производительности – очень важно протестировать веб-сайт/онлайн-магазин/приложение на производительность. Платежная система не должна выходить из строя, если несколько пользователей пытаются совершить транзакции одновременно.
- Тестирование безопасности – во время транзакции клиент предоставляет конфиденциальную информацию: номер кредитной карты, CVV-номер и т.д. Очень важно убедиться, что она передается в зашифрованном виде, и что канал надежно защищен.
Полезные советы
Основываясь на моем личном опыте, я собрал некоторые полезные советы для тестировщиков:
1. Узнайте, доступна ли бесплатная тестовая среда (для пробных и исследовательских целей) для платежного шлюза, который необходимо протестировать или внедрить. Наличие тестовой среды безусловно полезно и дает команде дополнительную гибкость для настройки инструмента и его углубленного тестирования.
2. Убедитесь, что транзакция протестирована от начала до конца. В наших проектах во время тестирования мы сообщали о многочисленных ошибках, связанных с фиксацией данных и потоком данных от приложения к платежному шлюзу. Вот некоторые из ошибок, с которыми мы столкнулись:
- Информация об имени клиента (покупателя) не была корректно зафиксирована.
- Дата истечения срока действия кредитной карты клиента фиксировалась неправильно из-за некорректной функции. Это приводило к тому, что банк-эмитент отклонял транзакции из-за неверной информации о кредитной карте.
- В платежной системе отображалась задвоенная транзакция.
3. Изучите ограничения тестовых сред платежных шлюзов.
Например, тестовая среда Authorize.net поддерживает одну валюту для каждого окружения. Если вам нужно протестировать несколько валют, вам нужно будет настроить разные тестовые среды. Кроме того, вы никогда не сможете “по-настоящему” протестировать, как будет вести себя система, когда учетная запись Authorize.net будет обрабатывать мультивалютные транзакции.
4. Если платеж по какой-либо причине не проходит во время транзакции, клиенту должно отображаться соответствующее сообщение. Любое технически сложное сообщение об ошибке, например, “Объект не установлен в качестве экземпляра” или “Ошибка 404” может запутать пользователя и повлиять на его впечатление.
Также рекомендуется показывать клиенту универсальное сообщение, например: «Кажется, возникла проблема с обработкой транзакции. Свяжитесь с нами по телефону 1-800-800-8000».
5. Для проверки постпродакшн-релиза клиенту (владельцу приложения/сайта) необходимо создать реальный счет платежной системы, настроить свой ID торгового субъекта и т.д.
В зависимости от выбранной платежной системы, настройка счета может занять от 2 дней до нескольких недель. Менеджер проекта должен заранее сообщить об этом клиенту, чтобы у него было достаточно времени для настройки реального счета, прежде чем начнется интеграция приложения и платежной системы.
Чек-листы и тест-кейсы для тестирования платежных шлюзов
Тестирование платежных систем, как и любых других приложений, предполагает правильное планирование.
Следующий чек-лист может быть полезен для тестировщиков в качестве справочного материала:
1. Настройте тестовую среду платежной системы.
2. Соберите номера различных тестовых кредитных карт, которые будут использоваться в процессе тестирования. Например, такую информацию для платежной системы Braintree можно найти на сайте Braintree payments.
3. Проверьте поведение приложения в случае успешной транзакции.
4. После успешной транзакции проверьте, возвращает ли платежный шлюз в ваше приложение какое-либо сообщение об успешной транзакции (подтверждающее сообщение).
5. Проверьте, получает ли покупатель какое-либо уведомление о подтверждении транзакции, например, электронное письмо с подтверждением заказа и т.д., если транзакция прошла успешно.
6. Проверьте, что происходит, если платеж не проходит или платежная система перестает отвечать – возникает какое-либо сообщение об ошибке?
7. Проверьте поведение приложения при включенном и выключенном блокировщике всплывающих окон в браузере. Это может быть полезно, если во всплывающем окне отображаются какие-либо подтверждающие сообщения.
8. Проверьте различные настройки предотвращения мошенничества/настройки безопасности.
Например, если платежная информация покупателя не совпадает с адресом, предоставленным банку-эмитенту, любое несоответствие приведет к отклонению транзакции.
9. Проверьте записи о транзакциях в базе данных, если у тестировщика есть к ней доступ.
10. Проверьте, что происходит, когда заканчивается сессия клиента.
11. Проверяйте консоль в течение всей транзакции и сообщайте о любых обнаруженных ошибках.
12. Проверьте, что транзакция выполняется по защищенному каналу.
Например, страницы оформления заказа могут быть HTTPS, тогда как остальные страницы сайта – HTTP.
13. Убедитесь, что валюта платежной системы настроена правильно.
Например, если приложение/веб-сайт относится к канадской компании/розничному продавцу, платежная система должна быть настроена на прием валюты CAD (канадских долларов).
14. Если у приложения имеется несколько вариантов оплаты, например, одновременно кредитная карта и PayPal, оба варианта должны быть протестированы по отдельности от начала до конца.
15. Убедитесь, что сумма возврата или аннулирования (на портале администратора платежной системы) совпадает с суммой транзакции. Сумма возврата или аннулирования ни в коем случае не должна превышать сумму транзакции.
Заключение
Платежная система является очень важным компонентом любого приложения электронной коммерции, предназначенного для приема платежей от своих клиентов. Поэтому очень важно тщательно протестировать этот компонент. Любой пропущенный тестовый сценарий может повлиять на продажи/транзакции и негативно сказаться на пользовательском опыте.
Тестировщики должны подготовить или настроить тестовую среду (тестовые окружения, сбор информации о тестовых кредитных картах, коды ответов и т.д.) и сформулировать стратегию тестирования – как для тестовой среды, так и для проверки реального/постпродакшн-релиза.