1.4. Server-to-Server Payout

Introduction

Payout is a type of transaction which results in funds transfer from Connecting Party banking account to customer (receiver) banking account or digital wallet. Payout transaction in most cases is used for bank account funding.

See terms definitions in Glossary.

Payout Flow

@startuml
participant Получатель as R
participant "Присоединяющаяся Сторона" as cp
autonumber
group Опционально
R -> cp : Инициализация
activate cp
end
== Запрос на выплату ==
cp -> "Payneteasy": /api/v4/payout/
activate "Payneteasy"
"Payneteasy" --> cp: ИД транзакции
group Опционально
cp -> "Payneteasy": Получение статуса по ИД транзакции\napi/v2/status
"Payneteasy" --> cp : Ответ со\nстатусом,redirect-to
cp -> R: Предоставлние URL-а перенаправления
deactivate "Payneteasy"
deactivate cp
activate R
R -> "Payneteasy": Перенаправление на redirect-to
deactivate R
activate "Payneteasy"
"Payneteasy" -> R: Дополнительная форма подстверждения
deactivate "Payneteasy"
activate R
R -> "Payneteasy": Подтверждение формы
deactivate R
activate "Payneteasy"
end
"Payneteasy" --> "Payneteasy": PОбработка\nвыплаты
group Получение финального статуса
== Получение обратного вызова \nПрисоединяющейся Стороны ==
cp <- "Payneteasy" : Обратный вызов с финальным статусом
"Payneteasy" <-- cp: HTTP 200
deactivate "Payneteasy"
== Запрос статуса ==
cp -> "Payneteasy": Получение статуса по ИД транзакции\napi/v2/status
activate "Payneteasy"
"Payneteasy" --> cp : Ответ со\nстатусом,order-stage
deactivate "Payneteasy"
end
group Опционально
cp --> R: Показ результата
deactivate cp
end
@enduml

(1) Payout can be initiated by Connecting Party based on internal business model or Receiver’s request.
(2) To implement payout transaction see /api/v4/payout.
(5) Some payout methods require the Receiver to fill the additional data on the form. The form to redirect the customer will return in status response in redirect-to parameter.
(8) The Receiver submits the payout form.
(9) The Receiver gets redirected back to Connecting Party. See Final redirect.
(11) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(13) To implement callback with final status handling see Connecting Party Callback.
(15) Final Status can be sent by Connecting Party based on internal business model or by Receiver’s request.