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) Для имплементации запроса на перевод см. /api/v4/transfer/. См. Процесс прохождения 3DS для получения большей информации про процесс 3DS. См. Схема прохождения 3DS и Реализация Сценариев 3DS, чтобы корректно реализовать проведение 3DS для переводов. Для сценариев deposit to PAN и deposit to RPI процесс 3DS не инициируется (Сценарий оплаты без 3DS).
(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) Если ячейки html и redirect-to присутствуют, см. Упрощённый сценарий аутентификации с html страницей
(5) То же, что и пункт (1).

Примечание

Схема принятия решений 3DS демонстрирует инициацию и проведение 3DS Платежным Шлюзом.3DS инициируется Платежным Шлюзом и проводится на стороне Подключаемой Стороны. Подробнее см. Обзор 3DS

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

Оплата считается проведённой без прохождения 3DS (без 3DS аутентификации) при нижеприведённых условиях:

Соблюдены шаги 1-2-(5)-6 Схемы Прохождения 3DS.
Отсутствие параметров tds_status, html и redirect-to.
Транзакция получила финальный статус (подтверждено, отклонено, ошибка, отфильтровано).

Примечание

Статус «unknown» могут получать как транзакции прошедшие 3DS, так и транзакции без прохождения 3DS. Детальнее о статусах транзакций см. Статусы.

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

<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) и (2). Для имплементации запроса статуса заказа, см. /api/v2/status/.
(9) Для инициации финального перенаправления см. Финальное перенаправление.
(10) HTML-страница ожидания на стороне Присоединяющейся Стороны может иметь индивидуальный дизайн и должна взаимодействовать с сервером Присоединяющейся стороны, как описано в диаграмме.
(15) и (16) то же, что и (1) и (2).