Процесс интеграции

На данной странице описаны основные аспекты процесса интеграции мерчантов с платёжной системой по Merchant API.

Будет сообщено тех. специалистами платёжной системы

1. <YOUR-API-KEY> - ваш API-ключ мерчанта [для stage и prod контуров]. См. страницу "Авторизация запросов"
2. <host> - имя хоста платёжной системы для отправки запросов [для stage и prod контуров]
3. URL-адреса и креды для ЛК мерчанта (Web GUI) [для stage и prod контуров]
4. methodID для отправки запросов на создание ордеров
5. Список названий банков, доступных для вывода (PayOut)
6. Список названий банков, доступных для ввода (PayIn)
7. Отдельные условия обязательности полей в запросах
8. Публичный RSA-ключ для проверки подписи вебхуков [для stage и prod контуров]. См. страницу "Коллбэки"

stage и prod контуры

Для тестирования интеграции используется отдельный stage-контур. Созданные в нём ордера никак не влияют на имеющиеся в prod контуре ордера.

Тестирование в prod возможно только после успешной отладки на stage!

Условия для тестирования в stage

• Заказы с суммой менее 10_000 у.е. (невключительно) будут успешно обработаны
• Заказы с суммой более 10_000 у.е. (включительно) будут отклонены

Кроме того, на stage-контуре доступны магические суммы для автоматизации тестов - они позволяют самостоятельно получить нужный терминальный статус ордера, без помощи оператора системы:

Сумма	Кейс	Исход
11	Депозит или выплата в успехе	succeeded
22	Клиент перевёл после закрытия ордера	succeeded_by_appeal
33	Клиент перевёл другую сумму	succeeded_by_appeal
44	Депозит или выплата в фейле	зависит от направления

Путь к терминальному статусу:

• 11 - ордер уходит в succeeded
• 22 - ордер уходит в expired, затем закрывается через системную апелляцию в succeeded_by_appeal на ту же сумму
• 33 - ордер уходит в expired, так как суммы не совпадают, затем закрывается через системную апелляцию в succeeded_by_appeal на новую сумму 100 (33 + переплата 67)
• 44 - PayIn уходит в expired, PayOut - в all_terminals_failed