1.14. Повторная предавторизация, списание и отмена

Введение

Оплата — тип транзакции, при которой банк блокирует определённую сумму на карте Плательщика и не позволяет использовать эту сумму. Важно учесть, что блокирование средств действует в течение определённого периода (обычно это до 7 дней для дебетовых карт и до 28 дней для кредитных карт).

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

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

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

Повторная оплата совершается в 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: Возврат ИД токена карты deactivate B A -> A: Сохранение ИД токена карты \nв профиле Плательщика 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: Получение ИД токена карты \nиз профиля Плательщика group Опционально A -> Плательщик: Запрос CVV Плательщика Плательщик --> A: Ввод CVV end A -> B: api/v2/make-rebill-preauth/ 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 --> Плательщик: Показ результата 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-preauth/. См. Схему прохождения 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) Если значения 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

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

Сценарий списания

skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 100 skinparam sequenceParticipant underline actor Плательщик participant "Присоединяющаяся Сторона" as A participant "Платёжный Шлюз" as B hnote over Плательщик,B : Успешная транзакция преавторизации autonumber == Списание == group Опционально Плательщик -> A: Инициация списания activate Плательщик activate A end A -> B: api/v2/capture activate B B --> A: ИД транзакции B -> B: Обработка списания group Получение финального статуса == Получение обратного вызова == A <- B: Обратный вызов с финальным статусом A --> B: HTTP 200 deactivate B == Запрос статуса == A -> B: Получение статуса по ИД транзакции api/v2/status activate B B --> A: Ответ со статусом, Order-stage deactivate B end group Опционально A --> Плательщик: Конечный статус deactivate Плательщик deactivate A end

(1) Списание может быть инициировано Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.
(2) Для имплементации запроса на списание см. /api/v2/capture/.
(5) Обратный вызов по списанию будет отправлен только в случае, если notify_url был предоставлен в инициирующем запросе предавторизации или дополнительный обратный вызов установлен на предоставленный URL для списаний на уровне терминала. Если в запросе предавторизации был предоставлен server_callback_url, обратный вызов по списанию не будет отправлен. Для обработки обратных вызовов см. Обратный вызов Присоединяющейся Стороны.
(7) Для имплементации запроса статуса заказа, см. /api/v2/status/. Статус должен запрашиваться несколько раз с интервалом в 3-5 секунд до получения финального статуса.
(9) Конечный статус может быть предоставлен Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.

Сценарий отмены

skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 100 skinparam sequenceParticipant underline actor Плательщик participant "Присоединяющаяся Сторона" as A participant "Платёжный Шлюз" as B hnote over Плательщик,B : Успешная транзакция преавторизации autonumber == Отмена == group Опционально Плательщик -> A: Инициация отмены activate Плательщик activate A end A -> B: api/v2/return activate B B --> A: ИД транзакции B -> B: Обработка отмены group Получение финального статуса == Получение обратного вызова == A <- B: Обратный вызов с финальным статусом A --> B: HTTP 200 deactivate B == Запрос статуса == A -> B: Получение статуса по ИД транзакции api/v2/status activate B B --> A: Ответ со статусом, Order-stage deactivate B end group Опционально A --> Плательщик: Конечный статус deactivate Плательщик deactivate A end

(1) Отмена предавторизации может быть вызвана Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.
(2) Для имплементации запроса на отмену см. /api/v2/return/.
(5) Обратный вызов по отмене будет отправлен только в случае, если notify_url был предоставлен в инициирующем запросе предавторизации или дополнительный обратный вызов установлен на предоставленный URL для отмен на уровне терминала. Если в запросе предавторизации был предоставлен server_callback_url, обратный вызов по отмене не будет отправлен. Для обработки обратных вызовов см. Обратный вызов Присоединяющейся Стороны.
(7) Для имплементации запроса статуса заказа, см. /api/v2/status/. Статус должен запрашиваться несколько раз с интервалом в 3-5 секунд до получения финального статуса.
(9) Конечный статус может быть предоставлен Присоединяющейся Стороной в соответствии с бизнес-моделью или по запросу Плательщика.