1.13. Recurring Payments Service

Introduction

Recurring (also Recurrent) transaction is a type of bank payment, where charges are applied to a cardholder in predetermined intervals for services or goods of an ongoing nature (memberships, subscriptions, loan payments). Prior to the charges, card must be registered in Payment Gateway. Recurring Payments Service enables automatic processing of payments on a regular schedule, such as daily, weekly, monthly, or annually. With this service, Payers can set up their payment details once, and the system will automatically charge their credit card or bank account at the specified intervals. The Connecting Party is not required to specify the recurring schedule on Payment Gateway side: the recurring payment requests can also be initiated manually according to Connecting Party internal schedule, business model or Payer’s request. To view and manage recurring payments service from UI, contact support manager.

Direct Recurring Payments Flow

This flow implies that Connecting Party has PCI DSS certificate and is able to work with cardholder data.

$@startuml skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 1200 skinparam sequenceParticipant underline actor Payer participant "Connecting Party" as A participant "Billblend" 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) To create recurring payment see /api/v4/create-recurring-payment/. To create recurring payments for multiple Payers in a single request with CSV data see /api/v4/create-recurring-payments/.

(7, 8, 13, 14, 20, 21) To implement callback with final status handling see Connecting Party Callback.

(10) To process recurring payment see /api/v4/process-recurring-payment/. To process recurring payments for multiple Payers in a single request with CSV data see /api/v4/process-recurring-payments/.

(16)To update recurring payment see /api/v4/update-recurring-payment/. To update recurring payments for multiple Payers in a single request with CSV data see /api/v4/update-recurring-payments/.

(6, 19) According to schedule means that if the schedule is set, the system will automatically process transactions at the specified intervals, update the profile and notify the Connecting Party of each completed transaction. If the schedule is not set, client can be charged only manually via UI or API call. The schedule can be changed later (see step 16).

(9, 15, 22) Payment results can be sent by Connecting Party based on internal business model or Payer’s request.

Recurring Payments With Initial Transaction Flow

In contrast to Direct Recurring Payments Flow, in Recurring Payments With Initial Transaction Flow the initial payment must be performed to verify and authorize the Payer’s card. Any transaction type that contains payment data will be suitable for this purpose: sale, preauth, transfer, etc. That transaction must be previously processed in Payment Gateway and have final status.

This flow doesn’t contain cardholder data in communication between Payer and Connecting Party, as well as between Connecting Party and Payment Gateway, therefore, PCI DSS certification for Connecting Party is not required.

$@startuml skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 1200 skinparam sequenceParticipant underline actor Payer participant "Connecting Party" as A participant "Billblend" 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$

Discuss with support manager which API Use-Case will be most suitable for initial payment.

(2) To initiate Card registration request and get Recurring Payment ID see api/v4/create-card-ref.

(9, 10, 16, 17) To implement callback with final status handling see Connecting Party Callback.

(6) To process recurring payment see /api/v4/process-recurring-payment/. To process recurring payments for multiple Payers in a single request with CSV data see /api/v4/process-recurring-payments/.

(12) To update recurring payment see /api/v4/update-recurring-payment/. To update recurring payments for multiple Payers in a single request with CSV data see /api/v4/update-recurring-payments/.

(15) According to schedule means that if the schedule is set, the system will automatically process transactions at the specified intervals, update the profile and notify the Connecting Party of each completed transaction. If the schedule is not set, client can be charged only manually via UI or API call. The schedule can be changed later (see step 12).

(11, 18) Payment results can be sent by Connecting Party based on internal business model or Payer’s request.