1.12. Повторная оплата

Введение

Повторная оплата (рекуррентный платёж) - это тип транзакции, при которой Плательщик получает товар или услугу от Присоединяющейся Стороны в обмен на деньги или другие активы с повторным использованием ранее сохранённого средства оплаты. Повторная оплата может быть инициирована вручную по инициативе Плательщика (таким образом можно упростить оплату для Плательщика), либо автоматически с заданным интервалом по инициативе Присоединяющейся Стороны (например, в модели подписки). Плательщику не требуется повторно заполнять платёжные данные, Присоединяющая Сторона использует Ссылочный идентификатор (Card Reference ID) для инициации оплаты. Необходимость проведения 3DS и ввода защитного кода (CVC, CVV и т.п.) в случае оплаты картой определяется настройками счёта в Эквайере и зависит от модели бизнеса Присоединяющейся стороны.

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

Повторная оплата совершается в 3 стадии:
1. Первый платёж – необходимо совершить первую оплату для проверки платёжного средства (например, карты) Плательщика. Для первого платежа подходит любой тип транзакции с платёжной информацией Плательщика - sale, preauth, transfer, и др.
2. Регистрация карты (или иного платёжного метода) – необходимо получить Ссылочный идентификатор (Card reference ID) и привязать его к профилю Плательщика. Регистрация платёжного метода возможна только для транзакций в финальном статусе.
3. Повторный платёж – необходимо вызвать новую транзакцию оплаты с использованием ссылочного идентификатора, полученного на предыдущем шаге.

Сценарий повторной оплаты

skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 1200 skinparam sequenceParticipant underline actor Плательщик participant "Присоединяющаяся Сторона" as A participant "Платёжный Шлюз" as B autonumber hnote over Плательщик,B : Изначальная оплата == Регистрация карты == A -> B: api/v2/create-card-ref/ activate B activate A B --> A: Возврат токена ID карты deactivate B A -> A: Сохранение токена ID карты в профиле Плательщика deactivate A == Получение информации карты == group Опционально A -> B: api/v2/get-card-info/ activate A activate B B --> A: Возврат информации карты deactivate A deactivate B end == Повторяющийся платёж == group Опционально Плательщик -> A: Инициация повторяющегося платежа activate A activate Плательщик end A -> A: Получение токена ID карты из профиля Плательщика group Опционально A -> Payer: Запрос CVV Плательщика Плательщик --> A: Подтверждение CVV end A -> B: api/v2/make-rebill-sale/ activate B B --> A: Ответ с ИД транзакции hnote over Плательщик,B : См. Схема прохождения 3DS group Получение финального статуса == Получение обратного вызова == A <- B: Обратный вызов с фианальным статусом A --> B: HTTP 200 deactivate B == Запрос статуса == A -> B: Получение статуса по ИД транзакции activate B B --> A: Конечный статус deactivate B end group Опционально A --> Плательщик: SПоказ результата deactivate Плательщик deactivate A end

Примечание

Тип транзакции и имплементация первого платежа зависит от бизнес-модели Присоединяющейся Стороны. Свяжитесь с отделом поддержки SBC для получения подходящего интеграционного сценария для проведения первого платежа.

(1) Для регистрации карты и получения ссылочного идентификатора см. /api/v2/create-card-ref/.
(4) Для выполнения запроса на получение информации по ссылочному идентификатору см. /api/v2/get-card-info/. Содержимое ответа на этот запрос может быть использовано для показа Плательщику деталей предыдущего использованного метода оплаты или обновления базы данных Присоединяющейся Стороны. Запрос может быть выполнен в любой момент, если у Присоединяющейся стороны уже есть ссылочный идентификатор (Card reference ID).
(6) Повторный платёж может быть инициирован Плательщиком или Присоединяющейся Стороной в соответствии с бизнес-моделью.
(8, 9) Присоединяющаяся Сторона отправляет запрос Плательщику для ввода CVV/CVC (если применимо для сценария повторной оплаты).
(10) Для инициирования транзакции рекуррентной продажи см. /api/v2/make-rebill-sale/. По умолчанию 3DS инициируется и выполняется платежным шлюзом через Упрощенную схему аутентификации. См. Схему принятия решения по 3DS.
(12) Для имплементации обратного вызова с обработкой финального статуса см. Обратный вызов Присоединяющейся Стороны.
(14) Для имплементации запроса статуса, см. /api/v2/status/. Статус должен запрашиваться несколько раз с интервалами в 3-5 секунд до получения финального статуса в ответе.
(16) Результаты транзакции могут отправляться Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.

Схема прохождения 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торона имлементирует шаги, указанные зелёным и фиолетовым цветом. Ниже указано описание шагов со ссылками на исполняемые API команды в соответствии с номером шага:

(1) Для имплементации запроса статуса, см. /api/v2/status/. Статус должен запрашиваться несколько раз с интервалами в 3-5 секунд до получения финального статуса в ответе.
(4) Если присутствуют значения html и redirect-to, см. Упрощённый сценарий аутентификации с html страницей.
(5) То же, что и пункт (1).

Примечание

The 3DS decision making schema is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see 3DS Overview and contact support manager.

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