1.5. Подтверждение счёта с прямой передачей данных

Введение

Верификация аккаунта - это нефинансовая транзакция, позволяющая проверить и зарегистрировать информацию аккаунта Плательщика. Эта процедура верификации помогает предотвратить потенциальную мошенническую активность и соответствовать отраслевым требованиям. Верификации аккаунта происходит с прямой передачей карточных данных в запросе Присоединяющейся Стороны в Платёжный Шлюз.

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

Сценарий верификации аккаунта

skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Плательщик
participant "Присоединяющаяся Сторона" as A
participant Payneteasy as B
autonumber
Плательщик -> A: Инициализация
activate A
A -> B: /api/v2/account-verification/
activate B
B --> A: ИД транзакции
B -> B: Обработка\nВерификации аккаунта
hnote over Плательщик,B : См Схема прохождения 3DS
group Получение финального статуса
== Получение обратного вызова \nПрисоединяющейся Стороны ==
A <- B: Обратный вызов \nс финальным статусом
A --> B: HTTP 200
deactivate B
== Запрос статуса ==
A -> B: Получение статуса по ИД транзакции
activate B
B --> A: Конечный статус
deactivate B
end
A --> Плательщик: Показ результата
deactivate Плательщик
deactivate A

(2) Для имплементации запроса на верификацию аккаунта см. /api/v2/account-verification/. См. Процесс 3DS для получения большей информации про процесс 3DS. См. Схема прохождения 3DS и Реализация Сценариев 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. Соблюдены шаги 1-2-(5)-6 Схемы Прохождения 3DS.
2. Отсутствие параметров tds_status, html и redirect-to.
3. Транзакция получила финальный статус (approved, declined, error,filtered).

Примечание

Транзакции со статусом «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) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
(15) и (16) то же, что и (1) и (2).