1.8. Recurring Payments Service

Introduction

Recurring (also Recurrent) payments transactions is a type of bank payments, 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 system. Recurring Payments Service enables automatic processing of payments on a regular schedule, such as 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 "Elecsnet" 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 request see /api/v4/create-recurring-payment/. To create recurring payments multiple request see /api/v4/create-recurring-payments/. The difference between the single and Multiple APIs is that the Multiple uses a CSV file, the payload parameter, as well as processing many “Create recurring payments” at once.
(7, 8, 13, 14, 20, 21) To implement callback with final status handling see Connecting Party Callback.
(10) To process recurring payment request see /api/v4/process-recurring-payment/. To process recurring payments multiple request see /api/v4/process-recurring-payments/. The difference between the single and Multiple APIs is that the Multiple uses a CSV file, the payload parameter, as well as processing many “Process recurring payments” at once.
(16) To update recurring payment request see /api/v4/update-recurring-payment/. To update recurring payments multiple request see /api/v4/update-recurring-payments/. The difference between the single and Multiple APIs is that the Multiple uses a CSV file, the payload parameter, as well as processing many “Update recurring payments” at once.
(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 payer of each completed transaction. If set as manual, client can be charged only manually with the help of Recur transaction/API call.
(9, 15, 22) Results of operation 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 initial payment should be performed to verify and authorize the Payer’s card. Any transaction type that uses personal data will be suitable for this purpose: sale, preauth, transfer, etc.
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.

Note

Transactions must be in the final status.

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

(2) To initiate Card registration request and get Card reference 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 request see /api/v4/process-recurring-payment/. To process recurring payments multiple request see /api/v4/process-recurring-payments/. The difference between the single and Multiple APIs is that the Multiple uses a CSV file, the payload parameter, as well as processing many “Process recurring payments” at once.
(12) To update recurring payment request see /api/v4/update-recurring-payment/. To update recurring payments multiple request see /api/v4/update-recurring-payments/. The difference between the single and Multiple APIs is that the Multiple uses a CSV file, the payload parameter, as well as processing many “Update recurring payments” at once.
(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 payer of each completed transaction. If set as manual, client can be charged only manually with the help of Recur transaction/API call.
(11, 18) Results of operation can be sent by Connecting Party based on internal business model or Payer’s request.