Реализация подключения модуля платежной системы для клиентов через api
Независимо от реализации ПО должно соответствовать важным требованиям к функционалу.
- Для реализации необходимо использовать апи
- Итоговое ПО должно представлять из себя готовое решение, для последующей интеграции в целевом продукте мерчанта + документация по использованию, например, в markdown формате.
- Нужно заложить функционал опционального изменения baseUrl для запросов, (дефолтно апи находится по урлу - https://api.merchant001.io/, однако в случае необходимости, нужно дать возможность заменить этот урл мерчантом)
- формат запросов на создание транзакции, выводов и так далее важно сделать расширяемым (В случае последующего изменения формата данных, структуры запросв (то есть, как минимум добавление новых полей не должно ломать интеграцию с нашим АПИ. (есть плохой кейс с нашим python sdk)))
- Должен быть понятный и "обычный" (для продукта (например у вордпресса это плагин, с настройками через интерфейс)) флоу добавления токена авторизации при интеграции мерчантом.
- Если ожидается хранение токена авторизации в БД продукта, то необходимо реализовать шифрование токена, для его хранения в зашифрованном виде. Токен в запросе передается без шифрования.
- Способы оплат: Есть 3 варианта запроса за способами оплат, для плагина и тд под ключ, реализация всех не обязательна, можно выбрать что-то из списка апи, обратите внимание на app.merchant001.io/merchant/api#/v2/payment-method/merchant/available-GET, там же есть еще 2 запроса рядом, с разными форматами ответа.
Базовый флоу интеграции мерчантом (различается в зависимости от целевого продукта (CMS, SDK, etc):
- сохранение токена авторизации
- вебхук (в том же вордпресс можно поднять endpoint для получения запросов)
- получение списка методов с группировкой по валютам. У мерчанта может быть несколько валют, необходимо дать ему их просмотр в админке и создание своих методов оплат на основе доступных ему с нашей платформы. При чем, если у него создать способ оплаты, но на нашей стороне мы его отключили, нужно внятно показать мерчанту, что ранее созданный им метод оплаты более не поддерживается + убрать его из вариантов выбора для клиентов мерчанта.
- создание транзакций на основе method из ручки способов оплат
- после создания транзакции у мерчанта может быть выбор флоу оплаты (обработка процесса оплаты на стороне приложения мерчанта ИЛИ переход на страницу оплаты (при желании отправить клиента на странциу оплаты, нужно передать cancelUrl, redirectUrl (в случае успешного завершения транзакции)))
Шаги (для процесса оплаты на стороне мерчанта)
- только после успешного создания можно запросить реквизиты по id транзакции.
- кнопка "оплатил" (опционально), это функция, меняющая статус транзакции на PAID (это не финальный статус, просто пометка от клиента, что он оплатил)
Обновление состояния транзакции.
Есть 2 варианта.
1. Установка webhookUrl (callbackUrl).
- Дефолтный webhookurl, в кабинете мерчанта на платформе, отвечает лишь за прослушивание транзакций на приемку средств.
- Есть возможность передачи callbackUrl параметра в запрос создания транзакции на приемку средств от клиентво мерчанта
- Так же есть ручка вывода средств мерчанта и установка callbackUrl в этом запросе (app.merchant001.io/merchant/api#/v1/withdraw/merchant-POST) (Для создания вывода организован свой список доступных методов для вывода, смотреть в апи доке на платформе)
2. Long pooling состояния транзакции по ID. Рекоммендуется делать данный запрос не чаще 1-2 раз в минуту.
Получение баланса мерчанта на платформе (можно глянуть в кабинете, либо сделать запрос. в доке - app.merchant001.io/merchant/api#/v1/transaction/merchant/balance-GET)
Отправка на проверку
В случае не верно переданной мерчантом суммы или долгого подтверждения в целом, необходимо использовать ручку загрузки чека по транзакции.
app.merchant001.io/merchant/api#/v1/transaction/merchant/receipt/:id-POST
По всем всем вопросам пишите на тг @cryptotechnik1