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

Введение

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

Примечание

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

(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 чтобы корректно реализовать проведение 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) 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

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

1. steps 1-2-(5)-6 of 3DS decision making schema were followed.
2. Отсутствие параметров tds_status, html и redirect-to.
3. 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) and (16) The same as point (1) and (2).