1.15. Сервис регулярных платежей

Введение

Повторяющаяся (также Рекуррентная) транзакция — это тип банковского платежа, при котором с держателя карты взимаются сборы в заранее определенные интервалы за услуги или товары постоянного характера (членство, подписки, платежи по кредитам). Перед взиманием сборов карта должна быть зарегистрирована в платежном шлюзе. Служба повторяющихся платежей обеспечивает автоматическую обработку платежей по регулярному графику, например, ежедневно, еженедельно, ежемесячно или ежегодно. С помощью этой службы плательщики могут настроить свои платежные реквизиты один раз, и система будет автоматически списывать средства с их кредитной карты или банковского счета с указанными интервалами. Присоединяющейся стороне не требуется указывать повторяющийся график на стороне платежного шлюза: запросы на повторяющиеся платежи также можно инициировать вручную в соответствии с внутренним графиком Присоединяющейся стороны, бизнес-моделью или запросом плательщика. Чтобы просмотреть и управлять услугой повторяющихся платежей из пользовательского интерфейса, свяжитесь со службой поддержки.

Процесс прямых повторяющихся платежей

Данный процесс подразумевает, что у Присоединяющейся стороны есть сертификат PCI DSS, позволяющий работать с данными держателей карт.

@startuml skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 1200 skinparam sequenceParticipant underline actor Payer participant "Connecting Party" as A participant "Payneteasy" as B autonumber Payer -> A: Subscribe for\nrecurring payments == Create recurring payment == activate A A -> B: /api/v4/create-recurring-payment/ activate B B -> B: Create recurring\npayment profile B --> A: Recurring Payment ID deactivate B Payer <-- A: Recurring payment\nis registered deactivate A group If recurring schedule is set ... According to schedule... B -> B: Process scheduled\nrecurring transaction activate B A <- B: Callback with Final Status activate A A --> B: HTTP 200 deactivate B Payer <-- A: Notify Payer deactivate A end group Optional == Process recurring payment == A -> B: v4/process-recurring-payment/\nwith Recurring Payment ID activate B activate A A <-- B: Creating recurring transaction B -> B: Process recurring\ntransaction A <- B: Callback with Final Status A --> B: HTTP 200 deactivate B Payer <-- A: Notify Payer deactivate A end group Optional == Update recurring payment == A -> B: v4/update-recurring-payment/\nwith Recurring Payment ID activate B activate A A <-- B: Updating recurring payment deactivate A B -> B: Update recurring\npayment profile group If recurring schedule is set deactivate B ... According to schedule... B -> B: Process scheduled\nrecurring transaction activate B A <- B: Callback with Final Status activate A A --> B: HTTP 200 deactivate B A --> Payer: Notify Payer deactivate A end end @enduml

(2) Чтобы создать повторяющийся платеж, см. /api/v4/create-recurring-payment/. Чтобы создать повторяющиеся платежи для нескольких Плательщиков в одном запросе с данными CSV, см. /api/v4/create-recurring-payments/.
(7, 8, 13, 14, 20, 21) Чтобы реализовать обратный вызов с обработкой окончательного статуса, см. Обратный вызов Присоединяющейся стороны.
(10) Для обработки повторяющихся платежей см. /api/v4/process-recurring-payment/. Для обработки повторяющихся платежей для нескольких Плательщиков в одном запросе с данными CSV см. /api/v4/process-recurring-payments/.
(16)Для обновления повторяющихся платежей см. /api/v4/update-recurring-payment/. Для обновления повторяющихся платежей для нескольких Плательщиков в одном запросе с данными CSV см. /api/v4/update-recurring-payments/.
(6, 19) Согласно расписанию означает, что если расписание установлено, система будет автоматически обрабатывать транзакции с указанными интервалами, обновлять профиль и уведомлять Присоединяющуюся сторону о каждой завершенной транзакции. Если расписание не установлено, средства могут быть списаны с клиента только вручную через пользовательский интерфейс или вызов API. Расписание можно изменить позже (см. шаг 16).
(9, 15, 22) Результаты платежа могут быть отправлены Присоединяющейся стороной на основе внутренней бизнес-модели или запроса Плательщика.

Процесс регулярных платежей с начальной транзакцией

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

@startuml skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 1200 skinparam sequenceParticipant underline actor Payer participant "Connecting Party" as A participant "Payneteasy" as B autonumber hnote over Payer,B : Initial payment Payer -> A: Subscribe for\nrecurring payments activate Payer activate A == Card registration == A -> B: Initiate card registration\nvia v4/create-card-ref activate B B -> B: Create recurring\npayment profile B --> A: Return Recurring Payment ID deactivate B Payer <-- A: Recurring payment\nis registered deactivate A deactivate Payer group Optional == Process recurring payment == A -> B: v4/process-recurring-payment/\nwith Recurring Payment ID activate B activate A A <-- B: Creating recurring transaction B -> B: Process recurring\ntransaction A <- B: Callback with Final Status A --> B: HTTP 200 deactivate B Payer <-- A: Notify Payer deactivate A end group Optional == Update recurring payment == A -> B: v4/update-recurring-payment/\nwith Recurring Payment ID activate B activate A A <-- B: Updating recurring payment deactivate A B -> B: Update recurring\npayment profile group If recurring schedule is set deactivate B ... According to schedule... B -> B: Process scheduled\nrecurring transaction activate B A <- B: Callback with Final Status activate A A --> B: HTTP 200 deactivate B A --> Payer: Notify Payer deactivate A end end @enduml

Обсудите с менеджером службы поддержки, какой вариант использования API будет наиболее подходящим для первоначального платежа.
(2) Чтобы инициировать запрос на регистрацию карты и получить идентификатор регулярного платежа, см. api/v4/create-card-ref.
(9, 10, 16, 17) Чтобы реализовать обратный вызов с обработкой окончательного статуса, см. Обратный вызов Присоединяющейся стороны.
(6) Для обработки повторяющихся платежей см. /api/v4/process-recurring-payment/. Для обработки повторяющихся платежей для нескольких Плательщиков в одном запросе с данными CSV см. /api/v4/process-recurring-payments/.
(12) Для обновления повторяющихся платежей см. /api/v4/update-recurring-payment/. Для обновления повторяющихся платежей для нескольких Плательщиков в одном запросе с данными CSV см. /api/v4/update-recurring-payments/.
(15) Согласно расписанию означает, что если расписание установлено, система будет автоматически обрабатывать транзакции с указанными интервалами, обновлять профиль и уведомлять Присоединяющуюся сторону о каждой завершенной транзакции. Если расписание не установлено, средства могут быть списаны с клиента только вручную через пользовательский интерфейс или вызов API. Расписание можно изменить позже (см. шаг 12).
(11, 18) Результаты платежа могут быть отправлены Присоединяющейсястороной на основе внутренней бизнес-модели или запроса Плательщика.