1.3. Прямой перевод средств

Введение

Перевод - это тип комплексной оплаты, которая позволяет перечислять средства между банковскими картами (PAN), карточными токенами (RPI) и банковским аккаунтом Присоединяющейся Стороны (Депозит).

См. определения терминов (Присоединяющаяся Сторона, 3DS метод и т.д.) в Глоссарии.

Возможные сценарии переводов:

PAN to PAN	Перевод PAN to PAN происходит при перечеслении средств с одной банковской карты на другую с указанием карточных номеров (не ссылочных идентификаторов).
PAN to RPI	Перевод PAN to RPI происходит при перечеслении средств с банковской карты с указанным номером карты на другую банковску карту с указанным ссылочным идентификатором.
RPI to PAN	Перевод RPI to PAN происходит при перечеслении средств с банковской карты с указанным ссылочным идентификатором на другую банковску карту с указанным номером карты.
RPI to RPI	Перевод RPI to RPI происходит при перечеслении средств с одной банковской карты на другую с указанием ссылочных идентификаторов карт (не номеров).
deposit to PAN	Перевод deposit to PAN происходит при перечеслении средств с аккаунта Присоединяющейся Стороны на банковскую карту с указанием номера карты.
deposit to PRI	Перевод deposit to PRI происходит при перечеслении средств с аккаунта Присоединяющейся Стороны на банковскую карту с указанием ссылочныго идентификатора карты.

Сценарий Переводов

skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
autonumber
actor Отправитель as Payer
participant "Присоединяющаяся Сторона" as A
participant "Платёжный Шлюз" as B

Payer -> A: Инициализация
activate A
== Запрос на перевод средств ==
A -> B: api/v4/transfer
activate B
B --> A: ИД транзакции
B -> B: Обработка платежа
hnote over Payer,B : См. Схема прохождения 3DS
group Получение финального статуса
== Получение обратного вызова \nПрисоединяющейся Стороны ==
A <- B: Обратного вызов с конечным статусом
B <-- A: HTTP 200
deactivate B
== Запрос статуса ==
A -> B: Получение статуса по ИД транзакции
activate B
B --> A: Конечный статус
deactivate B
end
A --> Payer: Показ результата
deactivate A

(1) Перевод между картами инициируется Отправителем. Перевод с Присоединяющейся Стороны (депозиты) инициируется Получателем по тому же сценарию.
(2) To implement transfer request see /api/v4/transfer/. See 3DS Overview to get more information about 3DS flow. See Схема прохождения 3DS and 3DS Implementation Scenarios to correctly implement 3DS flow for this Use-Case. For deposit to PAN and deposit to RPI cases 3DS is not initiated (flow is non3D).
(5) Для имплементации обратного вызова с обработкой финального статуса см. Обратный вызов Присоединяющейся Стороны.
(7) Для имплементации запроса статуса, см. /api/v2/status/. Статус должен запрашиваться несколько раз с интервалами в 3-5 секунд до получения финального статуса в ответе.

Схема прохождения 3DS

<style>
activityDiagram {
BackgroundColor #Turquoise
diamond {
BackgroundColor #Turquoise
}
}
document {
BackgroundColor #fcfcfc
}
</style>
title Схема прохождения 3DS
start
: (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
switch ((3) **html** and **redirect-to** field is present)
case (YES)
#Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
case (NO)
endswitch
backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
endwhile (YES)
:(6) Show result page to the Payer;
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
|<#Plum>| Connecting and other party |
| | Other Party |
endlegend

Присоединяющаяся Cторона имлементирует шаги, указанные зелёным и фиолетовым цветом. Ниже указано описание шагов со ссылками на исполняемые АПИ команды в соответствии с номером шага:

(1) Для имплементации запроса статуса, см. /api/v2/status/. Статус должен запрашиваться несколько раз с интервалами в 3-5 секунд до получения финального статуса в ответе.
(4) If html and redirect-to fields are present, see Simplified authentication flow with html page.
(5) The same as point (1).

Примечание

The 3DS decision making schema is showcasing 3DS being initiated and performed by Payment Gateway. 3DS is initiated by Payment Gateway and performed on Connecting Party side., see 3DS Overview

Сценарий оплаты без 3DS

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

steps 1-2-(5)-6 of 3DS decision making schema  were followed.
Отсутствие параметров tds_status, html и redirect-to.
transaction received final status (approved, declined, error, filtered).

Примечание

Please note that transaction status «unknown» might appear for both 3DS and non3D transactions. See details in Statuses.

Упрощённый процесс аутентификации

<style>
document {
BackgroundColor #fcfcfc
}
activitydiagram {
diamond {
BackgroundColor #Turquoise
}
}
</style>
title Упрощённый процесс аутентификации
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
**Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or uknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
**Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **Схема прохождения 3DS** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend

(1) and (2) To implement order status request see /api/v2/status/.
(9) Для инициации финального перенаправления см. Финальное перенаправление.
(10) HTML-страница ожидания на стороне Присоединяющейся Стороны может иметь индивидуальный дизайн и должна взаимодействовать с сервером Присоединяющейся стороны, как описано в диаграмме.
(15) и (16) то же, что и (1) и (2).