Тестирование и запуск

Чек-лист запуска нового Партнера

1. Этапы интеграции и тестирования

Интеграция и приемочное тестирование проводятся последовательно в двух контурах:

тестовый контур;

промышленный контур.

Переход между этапами выполняется только после подтверждения со стороны команды Rahmat Pay.

1.1. Тестовый контур

Первичная настройка и проверка интеграции выполняются в тестовом контуре.

На этом этапе:

Партнер получает тестовые URL и учетные данные;

настраиваются Deeplink, Callback и серверные методы API;

проверяются основные и альтернативные пользовательские сценарии;

выполняются обязательные тест-кейсы;

тестируются платежи, статусы, возвраты, сверка и передача фискальной ссылки;

проверяются обработка ошибок, повторные запросы и идемпотентность;

устраняются обнаруженные ошибки и несоответствия.

Переход к тестированию в промышленном контуре допускается только после успешного прохождения обязательных тест-кейсов в тестовом контуре и получения подтверждения от команды Rahmat Pay.

1.2. Промышленный контур

После завершения тестирования в тестовом контуре Партнеру предоставляются параметры подключения к промышленному контуру.

В промышленном контуре проводится ограниченное приемочное тестирование, в рамках которого:

проверяются доступность и корректность промышленных URL;

проверяются авторизация и формирование подписи запросов;

проверяется работа Deeplink, Universal Link и App Link;

выполняется контрольный платеж;

проверяется доставка и идемпотентная обработка Callback;

проверяется получение актуального статуса транзакции;

выполняется контрольный возврат;

проверяется передача фискальной ссылки;

выполняется контрольная сверка транзакций;

проверяются мониторинг и журналирование.

Контрольные операции в промышленном контуре выполняются только по предварительно согласованным сценариям и реквизитам.

Полноценный запуск интеграции допускается только после успешного тестирования в промышленном контуре и получения итогового подтверждения от команды Rahmat Pay.

Важно. Успешное тестирование в тестовом контуре не является разрешением на промышленный запуск. Партнер не должен переключать интеграцию на промышленный контур или открывать ее для Пользователей без согласования с командой Rahmat Pay.

2. Визуальное подтверждение (UI/UX)

Партнер должен предоставить команде Rahmat Pay скриншоты следующих экранов для iOS и Android.

2.1. Страница подтверждения оплаты

На экране должны отображаться:

логотип Rahmat;

наименование торговой точки;

сумма платежа;

валюта платежа;

источник списания;

кнопка подтверждения оплаты.

Сумма на экране Партнера должна полностью соответствовать сумме, полученной от Rahmat.

2.2. Страница успешной оплаты

На экране должны отображаться:

сообщение об успешной оплате;

сумма платежа;

наименование торговой точки;

идентификатор или дата операции;

кнопка «Вернуться», ведущая по адресу return_url.

Переход по return_url не должен инициировать повторный платеж.

2.3. Страница ошибки

На экране должны отображаться:

понятное Пользователю описание ошибки;

возможность вернуться в Rahmat или повторить операцию, если повторная попытка допустима;

кнопка возврата по адресу return_url, если он был передан.

Технические сообщения, внутренние коды, трассировки и другие служебные данные не должны отображаться Пользователю.

Если Rahmat возвращает код и описание ошибки в ответе API, Партнер должен корректно обработать их и показать Пользователю согласованное сообщение.

3. Обязательные тест-кейсы (QA)

Тест-кейсы сначала выполняются в тестовом контуре. После их успешного прохождения согласованный набор контрольных сценариев повторно проверяется в промышленном контуре.

Тестирование проводится на актуальных поддерживаемых версиях iOS и Android.

Каждый обязательный тест-кейс должен быть успешно пройден и подтвержден командой Rahmat Pay.

3.1. Внешнее сканирование QR-кода

Необходимо проверить следующий сценарий:

Пользователь сканирует QR-код Rahmat стандартной камерой устройства.

Открывается платежная страница Rahmat.

Пользователь выбирает приложение Партнера.

Выполняется переход по Deeplink в приложение Партнера.

В приложение передаются корректные параметры платежа.

Пользователь подтверждает оплату.

После завершения операции Пользователь возвращается по адресу return_url.

Rahmat получает Callback и переводит платеж в соответствующий статус.

Необходимо отдельно проверить сценарии, когда:

приложение Партнера установлено;

приложение Партнера не установлено;

Deeplink недействителен или не может быть открыт;

Пользователь отменяет переход или оплату.

3.2. Прямая оплата без WebView

Необходимо проверить следующий сценарий:

Пользователь сканирует QR-код встроенным сканером приложения Партнера.

Приложение распознает QR-код Rahmat.

Партнер получает информацию о платеже через API Rahmat.

Инвойс находится в статусе draft.

В приложении отображаются корректные данные платежа.

Пользователь подтверждает оплату.

Партнер отправляет Callback в Rahmat.

Платеж переходит в статус success.

Платеж не должен выполняться повторно при повторном открытии или сканировании того же QR-кода.

3.3. Обработка некорректного статуса инвойса

Необходимо проверить поведение приложения при сканировании QR-кода, связанного с инвойсом в одном из следующих состояний:

платеж уже успешно выполнен;

платеж отменен;

по платежу выполнен возврат;

срок действия платежа истек;

платеж находится в обработке;

платеж завершен с ошибкой;

платеж или инвойс не найден.

Партнер должен:

запретить повторное списание;

показать Пользователю понятное сообщение;

корректно обработать статус, полученный от Rahmat;

предоставить возможность безопасно закрыть экран или вернуться назад.

3.4. Интеграция через WebView

Необходимо проверить следующий сценарий:

Пользователь сканирует QR-код встроенным сканером приложения Партнера.

Страница Rahmat открывается во встроенном WebView.

WebView передает корректный User-Agent с названием и версией приложения.

Rahmat определяет, что страница открыта внутри приложения Партнера.

Пользователь переходит из WebView к подтверждению оплаты в приложении.

После завершения операции Пользователь возвращается на результирующую страницу Rahmat.

WebView корректно обрабатывает успешный платеж, отказ и отмену Пользователем.

Необходимо также проверить:

открытие всех разрешенных доменов Rahmat;

обработку Deeplink внутри WebView;

работу кнопки «Назад»;

повторное открытие страницы;

потерю и восстановление интернет-соединения;

невозможность повторного списания после обновления страницы.

3.5. Жизненный цикл транзакции

Необходимо проверить полный жизненный цикл платежа:

Создание платежа.

Переход Пользователя к оплате.

Подтверждение операции в приложении Партнера.

Отправка Callback в Rahmat.

Получение статуса success.

Проверка транзакции через Status API.

Передача фискальной ссылки.

Выполнение возврата через Refund API.

Получение статуса refund на стороне Партнера.

10.

Получение статуса revert на стороне Rahmat.

11.

Проверка операции в отчете сверки.

Дополнительно необходимо проверить:

повторную отправку Callback;

повторный запрос на возврат;

временную недоступность API Rahmat;

временную недоступность API Партнера;

сетевой тайм-аут с неизвестным результатом;

расхождение статусов между системами;

отсутствие повторного списания или возврата при повторных запросах.

4. Требования к Партнеру

4.1. Ссылки и маршрутизация

Партнер должен предоставить:

Universal Link для iOS;

App Link для Android;

кастомную URI-схему, если она используется;

Web Checkout URL для оплаты в мобильном браузере;

ссылку на приложение в App Store;

ссылку на приложение в Google Play;

return_url или правила его обработки;

перечень поддерживаемых доменов и маршрутов;

код платежного приложения app_name, согласованный с Rahmat Pay.

Все ссылки должны быть доступны по HTTPS, кроме согласованных кастомных URI-схем.

4.2. Тестовый контур

Для проведения интеграции Партнер должен предоставить:

URL тестового API;

тестовые учетные данные;

тестовые карты, счета или другие источники средств;

тестовые номера телефонов, если они необходимы;

инструкции по установке тестовой версии приложения;

тестовые Deeplink, Universal Link и App Link;

перечень тестовых кодов ошибок;

контакт ответственного технического специалиста.

Доступы к тестовому контуру должны быть предоставлены до начала интеграционных работ.

4.3. Промышленный контур

После успешного завершения тестирования в тестовом контуре Партнер должен предоставить:

URL промышленного API;

промышленные учетные данные;

параметры авторизации и проверки подписи;

промышленные Deeplink, Universal Link и App Link;

Web Checkout URL;

разрешенные IP-адреса, если используется фильтрация по IP;

контакты технических специалистов для оперативного взаимодействия;

порядок действий при инцидентах и недоступности API.

Промышленные учетные данные должны передаваться по защищенному каналу и не должны использоваться в тестовом контуре.

4.4. Серверные методы

До начала приемочного тестирования Партнер должен предоставить следующие методы:

Status API;

Refund API;

Reconciliation API;

Fiscal Link API;

ScanPay API — если сценарий поддерживается;

Web Checkout — если сценарий поддерживается.

Для каждого метода должны быть предоставлены:

URL тестового и промышленного контуров;

HTTP-метод;

формат авторизации;

правила формирования и проверки подписи;

ограничения по IP-адресам, если они используются;

тайм-ауты;

формат успешного ответа;

перечень кодов ошибок;

правила повторных запросов;

требования к идемпотентности.

5. Критерии готовности к запуску

Интеграция может быть допущена к промышленному запуску только после выполнения следующих условий:

интеграция настроена и проверена в тестовом контуре;

все обязательные тест-кейсы успешно пройдены в тестовом контуре;

получено подтверждение от команды Rahmat Pay о переходе к тестированию в промышленном контуре;

предоставлены и проверены промышленные URL и учетные данные;

успешно выполнены согласованные контрольные операции в промышленном контуре;

согласованы Deeplink, Universal Link и App Link;

проверена маршрутизация на iOS и Android;

подтвержден внешний вид всех обязательных экранов;

проверена идемпотентность платежей и возвратов;

успешно протестированы Callback, Status API и Refund API;

проверена передача фискальной ссылки;

выполнена контрольная сверка транзакций;

настроен мониторинг ошибок и доступности API;

настроено безопасное журналирование операций;

определены технические контакты для оперативного взаимодействия;

получено итоговое подтверждение готовности от команды Rahmat Pay.

Важно. Наличие успешно проведенного платежа не означает завершение интеграции. Запуск разрешается только после проверки полного жизненного цикла транзакции в тестовом и промышленном контурах и получения итогового подтверждения от команды Rahmat Pay.

Чек-лист запуска нового Партнера#

1. Этапы интеграции и тестирования#

1.1. Тестовый контур#

1.2. Промышленный контур#

2. Визуальное подтверждение (UI/UX)#

2.1. Страница подтверждения оплаты#

2.2. Страница успешной оплаты#

2.3. Страница ошибки#

3. Обязательные тест-кейсы (QA)#

3.1. Внешнее сканирование QR-кода#

3.2. Прямая оплата без WebView#

3.3. Обработка некорректного статуса инвойса#

3.4. Интеграция через WebView#

3.5. Жизненный цикл транзакции#

4. Требования к Партнеру#

4.1. Ссылки и маршрутизация#

4.2. Тестовый контур#

4.3. Промышленный контур#

4.4. Серверные методы#

5. Критерии готовности к запуску#

Чек-лист запуска нового Партнера

1. Этапы интеграции и тестирования

1.1. Тестовый контур

1.2. Промышленный контур

2. Визуальное подтверждение (UI/UX)

2.1. Страница подтверждения оплаты

2.2. Страница успешной оплаты

2.3. Страница ошибки

3. Обязательные тест-кейсы (QA)

3.1. Внешнее сканирование QR-кода

3.2. Прямая оплата без WebView

3.3. Обработка некорректного статуса инвойса

3.4. Интеграция через WebView

3.5. Жизненный цикл транзакции

4. Требования к Партнеру

4.1. Ссылки и маршрутизация

4.2. Тестовый контур

4.3. Промышленный контур

4.4. Серверные методы

5. Критерии готовности к запуску