# Тестирование платежного шлюза (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/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platezhnogo-shlyuza-payment-gateway.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.