# Тестирование платежного шлюза (Payment Gateway)

**Платежный шлюз** - это сервис, который помогает нам совершать денежную транзакцию в Интернете, он принимает кредитные карты, дебетовые карты, интернет-банкинг и другие способы оплаты от клиента для выполнения транзакции. Службы платежных шлюзов шифруют конфиденциальную информацию, такую ​​как номера карт, CVV, пароли, пин-коды и т. д. Они интегрированы с платформами электронной коммерции для совершения и получения платежей. С ростом цифровых платежей на платформах электронной коммерции мы должны предоставлять клиентам безопасные и удобные платежные шлюзы, которые могут выдерживать высокие нагрузки без каких-либо сбоев в работе. Некоторыми из распространенных примеров платежных шлюзов являются Paypal, Paytm, Razor pay, Instamojo и т. д.

**Терминология**:

* Торговец (Merchant): это лицо или компания, которые продают товар или услугу, они могут быть поставщиком услуг, продавцом товара, магазином электронной коммерции и т. д. Они принимают онлайн-платежи для своего бизнеса;
* Банк-эквайер (Acquiring bank): это банк продавца, когда клиент платит через платежный шлюз, сумма зачисляется в банк-эквайер;
* Банк-эмитент (Issuing bank): это банк клиента, когда продавец получает платеж, сумма вычитается из банка-эмитента;
* Транзакция: это платеж, сделанный в кассе платежного шлюза. Он генерирует уникальный идентификатор, который называется идентификатором транзакции;
* Авторизация: платежный шлюз отправляет запросы авторизации на счет клиента (банк-эмитент) для вычета суммы. Запрос авторизации может быть отклонен или одобрен банком-эмитентом;
* Аутентификация - это метод, с помощью которого банк проверяет личность клиента, совершающего платеж, это может быть CVV, OTP, PIN-код, пароль и т. д.

**Поток транзакций платежного шлюза**

![https://www.softwaretestingmaterial.com/wp-content/uploads/2021/09/Payment-Gateway-Transaction-Flow.webp?ezimgfmt=ng:webp/ngcb5](https://www.softwaretestingmaterial.com/wp-content/uploads/2021/09/Payment-Gateway-Transaction-Flow.webp?ezimgfmt=ng:webp/ngcb5)

* Клиент выбирает товар или услугу и получает страницу оплаты;
* Он вводит данные своей карты, такие как номер, CVV, срок действия и т. д. Эта информация надежно передается платежному шлюзу;
* Платежный шлюз шифрует данные карты и выполняет проверку на мошенничество, прежде чем отправить данные в банк-эквайер;
* Банк-эквайер надежно отправляет информацию в схемы карт, выполняет еще одну проверку на мошенничество и отправляет ее в банк-эмитент;
* Банк-эмитент проводит еще одну проверку на мошенничество и авторизует транзакцию. Сообщение об одобрении/отклонении отправляется Эквайреру через карточные схемы;
* Платежный шлюз получает это сообщение о принятии/отклонении, которое передает сообщение продавцу. Если платеж одобрен, Эквайрер получает платеж от банка-эмитента и вносит средства на счет продавца.

**Предварительные условия** (prerequisites) для тестирования платежного шлюза

* Соберите тестовые данные для тестовых дебетовой/кредитной карте;
* Соберите информацию, связанную с типом платежного шлюза, который мы собираемся протестировать;
* Определите параметры для тестирования производительности;
* Соберите информацию о кодах ошибок, которые могут возникнуть в платежном шлюзе, чтобы мы знали, возникла ли ошибка с нашей стороны или она связана с платежным шлюзом;
* Настройте среду Sandbox для проверки платежных систем без фактической оплаты.

**Виды тестирования платежного шлюза**

* **Functional Testing**: мы проводим функциональное тестирование для новых или непопулярных систем. Это жизненно важно, поскольку гарантирует, что система полностью функциональна и ее функции работают должным образом. Это помогает проверить как приложение, так и шлюз;
* **Security testing**: гарантирует, что платежный шлюз защищает данные, которые он обрабатывает во время оплаты. Он защищает систему от кибератак, хакеров и других уязвимостей безопасности. Мы должны убедиться, что мы заботимся о конфиденциальной информации, предоставленной клиентом;
* **Performance testing**: гарантирует, что приложение не выйдет из строя, если большое количество пользователей отправят платеж одновременно. Этот тип тестирования имеет решающее значение, особенно во время больших распродаж или праздничных сезонов;
* **Integration testing**: обычно платформа электронной коммерции или любое другое приложение, требующее оплаты, нуждается в интегрированном в систему платежном шлюзе. Интеграционное тестирование гарантирует, что платежный шлюз легко интегрируется с веб-сайтом продавца. Здесь мы проверяем размещение заказа, обработку платежей, подтверждение заказа, т.е. полный поток транзакций.

**Примеры тест-кейсов**:

* **Functional**:
  * Каждый вариант оплаты можно выбрать, в текстовые поля можно печатать;
  * Сохраненная кредитная/дебетовая карта доступна на странице оплаты;
  * Можно установить карту по умолчанию;
  * Клиент получает соответствующее уведомление по электронной почте и текст после успешного/неудачного платежа;
  * Платежный шлюз перенаправляет обратно в приложение после завершения платежа;
  * Правильно рассчитываются сумма, налоги, скидки, кредиты магазина и т. д.;
  * Система меняет формат валюты и языка по запросу пользователя;
  * Платеж не проходит, если какое-либо обязательное поле пусто;
  * Поведение системы при отключении интернета во время оплаты;
  * Поведение системы если сессия заканчивается;
  * Проверка двойной оплаты;
  * Проверка различных комбинаций действительных и недействительных данных для номера карты + срока действия + CVV;
  * Проверка работоспособности при наличии расширений браузера, например, блокировщиков рекламы;
  * Каждый вариант оплаты направляется в соответствующий поток платежей (payment flow).
* **Performance**:
  * Работоспособность платежного шлюза, когда несколько пользователей одновременно пытаются совершить транзакцию;
  * Быстро ли реагирует процессор;
  * Соответствует ли время, необходимое для того, чтобы приложение достигло платежного шлюза, требованиям;
  * Зачислена ли та же сумма клиенту во время возврата, а также проверьте сроки возврата в соответствии с положениями и условиями;
  * Обновляются ли детали транзакции в базе данных в правильном формате.
* **UI**:
  * labels и boxes видны;
  * Номер карты маскируется астерисками при вводе;
  * Логотип/название компании платежного шлюза видны;
  * Все варианты оплаты видны;
  * Цветовая схема соответствует спецификациям;
  * Правильные сообщения отображаются при успешном/неудачном платеже;
  * Разделы промокод, подарочная карта, купон видны;
  * Все ошибки или опечатки пользователя выделены красным цветом.
* **Security**:
  * Реквизиты карты маскируются;
  * Конфиденциальная информация шифруется;
  * Приложение защищено от межсайтового скриптинга, спуфинга и т. д.;
  * Онлайн-транзакция происходит по безопасному каналу, такому как HTTPS;
  * Проверьте все настройки предотвращения мошенничества/безопасности приложения.
  * Клиент получает одноразовый код (OTP) при инициировании транзакции со своих банковских реквизитов;
  * Также проверьте тот же сценарий с несколькими картами, привязанными к разным телефонным номерам в одной учетной записи.

Источники:

* [Payment Gateway Testing Guide: How To Test Payment Gateway Functionality](https://www.softwaretestingmaterial.com/payment-gateway-testing/)

Доп. материал:

* [Payment Gateway A/B Testing Guide - How to effectively test different payment providers and methods](https://securionpay.com/blog/payment-gateway-ab-testing/)