for developers and administrators
User Interface Reference
Resources (Directory Structure)
Zip and Country Codes
Supported Providers (Banks & Networks)
UniPay Codes & Code Mappings
Integrated 3rd Party Libraries
Diagrams and Documents
This section only
Recurring Billing Process Guide v1.1
Added on: 10/23/14
Updated on: 03/01/22
Table of Contents
The purpose of this guide is to familiarize merchants with the recurring billing process.
Let’s start by reviewing terminology.
This guide will be useful for
s and gateway users that want to understand how recurring billing occurs within the system.
is a record in the system, representing a person or an organization that signed up for a product or a service and is required to make recurring payments for it. Customer - An individual who purchases a
to a merchant’s goods/services and pays for them either through the gateway or through an external system (for example, a terminal not integrated with the gateway), in cash/by check.
Payment plan is a representation of a recurring billing pattern of regular nature (such as weekly, monthly, quarterly, annually plans). Payment plan will generally have a single date within a recurrence interval, on which the payment is to be collected.
is a financial transaction representing outstanding balance on a customer account that has to be paid. Revenue transactions can be of 3 types:
is a transaction type that represents the outstanding balance to be paid for a product or a service.
is an offsetting entry against an
, which can be used to negate the previously issued invoice, such as in case of a billing error. Credit can also be subsequently reversed (due to an error or some other reason); Cancel Credit transaction is used in such cases.
is a transaction type that represents a service fee (such as decline fee or late fee) that was assessed due to various business reasons.
is a financial transaction representing a payment collected from a customer. Asset transactions can be of 3 types:
is generally a one-time payment collected at point of sale or over the phone.
Claim is an attempt by internal recurring billing process to collect a recurring payment against the outstanding balance on a specific due date.
is a return of money back to the customer either due to an error or for some other reason.
Now that we’ve covered the fundamental terms, let’s continue with the review of the recurring billing process.
Recurring billing process is comprised of several subprocesses, which are explained in detail below:
Invoicing is the process of generation of
s based on the payment plans that are due on the billing date (e.g. today). As a result of the process, an invoice is generated for each payment plan that is due. The invoice is posted to the
that the payment plan is attributed to and, consequently, the outstanding balance on the account is increased.
Balancing 1 is the process during which payments (such as prepayments or any positive balance on the account) are allocated against outstanding invoices.
The allocation (balancing) process can be performed using different approaches (algorithms). There are two balancing algorithms that are most commonly used:
Oldest invoice first – any available payment will be allocated to the oldest outstanding invoice first, then to the second oldest and so on. This algorithm is often used for collections of past-due payments.
Newest invoice first – any available payment will be allocated to the most recently created invoice first, then to the invoice created right before it and so on. This algorithm is often used for billing invoices as well as for prepayments and POS purchases.
Billing is the process during which all the invoices are collected and claims are generated and submitted to the processing engine to charge the respective accounts and collect payments. The
remains open and the claims remain in pending status until the processing completes. Usually, depending on the decline recycling policy, the processing phase can take between 1 and 3 days.
Processing is the process during which respective submitted transactions are handled by the processing engine and associated accounts (bank accounts or payment cards) are charged with respective amounts.
Reprocessing is the process during which soft declines are reattempted based on predefined rules (around number of attempts and their frequency). This process often involves the use of credit card account updater.
Closeout is the process during which the result of processing is imported from the processing engine, and approvals and declines are posted to the respective customer accounts.
Fee Assessment is the process during which all newly imported declines are analyzed and respective decline
s are assessed. During this process, late fees can also be assessed on accounts with outstanding balance over a predefined time period.
Balancing 2 is the process which allocates newly posted payments against the
s generated as part of the invoicing process. As part of this process, all
s involved in the invoicing process are updated with their new balances. In case when submitted payments came back as approved, the balance is reduced to zero. In cases of declines, the balance is updated with the total of the outstanding balance of the invoices plus any fees that were generated within the fee assessment process.
Rebilling is essentially a billing process, which involves all of the phases explained above; however, it is generally done on the previously declined accounts. It can be implemented in various ways including reattempt of the last successful payment attempted or reattempt of the entire outstanding balance, including fees.
In the context of recurring billing, there may be customers unable to pay their debts on time. In these cases, the merchant needs to collect the debt amount from the customer. For cases when a merchant cannot recover a debt from the customer, it can convey information on the debt to a credit bureau agency. This can be done via the collections mechanism.
- a mechanism that allows for tracking the customers having a positive balance, notifying them about their debts, monitoring the process of debt recovering and reporting their debts to a collections bureau agency.
The mechanism functions at two levels:
Internally within the gateway, monitoring customers whose debts are formed as a result of an inability to make payments provisioned by a payment plan. For cases when a debt is not being paid off, a customer gets notified of the debt amount by the system.
Externally, which implies that the information about the debt amount is conveyed to a collections bureau agency after a respective notification is sent to a customer.
To enable the collections logic, the following parameters must to be set:
. To activate the collections mechanism, the following provider profiles have to be configured: credit reporting, skip tracing, letters and emails. An existing integration can be used. If a new integration is needed, an integration request should be sent to the support team. Since all provider profile settings are the same for all merchants within a portfolio, it is recommended to set the required provider profiles at the portfolio level rather than the merchant level.
. If a customer fails to pay off their debt, information on the debt amount is sent to a collections bureau agency (if this is specified in the customer agreement). To have collections information submitted to a collections bureau agency, a provider profile is required to be set.
. If it is necessary to update customers’ contact information, a skip tracing provider profile is required to be set.
. If it is necessary to notify customers about their debts by mail, a letters provider profile is required to be set.
. If it is necessary to notify customers about their debts by email, an emails provider profile is required to be set.
. After a customer’s balance becomes positive, the system counts a period (in days) from the moment the oldest debt was formed until the customer has to be switched to the external collections mode and their information can be sent to the collections bureau agency. This period is called the Сollections Period. It is currently set via the database per a request to the support team, but is will be returned to the user interface in an upcoming release. 3.
. If the gateway is used to send email notifications to a customer about a debt, certain email notification templates are required. To learn how to set a notification template, review the
How to add an email template
. To ensure that previously configured notifications are sent to customers, these steps should be followed:
To have mail/email notifications about a debt sent to a customer, a notification template code and a number of days after a debt is formed have to be set in the merchant’s billing settings. It is possible to set up to three notifications. This can be done at the Merchant perspective => Details => Billing => Emails/Letters => Notifications section.
To have mail/email notifications about debt information being conveyed to a collections bureau agency sent to a customer, a notification template code and a number of days after a customer is switched to the external collections mode have to be set in the merchant’s billing settings. It is possible to set up to five notifications. This can be done at the Merchant perspective => Details => Billing => Emails/Letters => Collections section.
External collections activation
. To ensure that the information about debts of the customers associated with a merchant is to be conveyed to the collections bureau agency, a respective parameter is required to be set at the merchant level. This can be done at the Merchant perspective => Details => Billing => Settings => Credit Bureau Reporting Status dropdown. 6.
. To work with customers that have debts to merchants, a user with a specific function, Collections Agent, has to be present within the system. Once set, a collections agent is populated as an option in the Agent field dropdown. To allow for an agent to work with a customer that goes through collections both internally and externally, the following fields are provided:
. To differentiate customers by certain criteria, the agent can set a priority. According to the indicated priority, the agent can monitor customers (for example, by the level of a debt) and make calls/send notifications with respect to the priority set. There are three options available:
- used for customers with high priority (for example, a customer having a recent debt is likely to recover it).
- used for customers with low priority (for example, a customer having a long standing debt is unlikely to recover it).
- used when a customer’s contact information has been updated.
. To determine the date when a customer was brought to collections and the number of days since this date, the Sent Date field is used. Additionally, this parameter can be used as a search criteria to locate customers that have debts falling within a specified time frame (Console perspective => Сustomers => List => Send date => Search).
. To determine the balance that was recorded when a customer was brought to collections, the Sent Balance field is used.
Last action date/last action
. When communicating with a customer on updating their debt status, an agent can add information on every predefined action via the Actions section. After being added, the information on the last interaction with a customer (a date/note of the last action) is recorded and populated in the Last Action and Last Action Date fields.
. To determine whether the information on a customer’s debt can be sent to the collections bureau agency, the agent can choose either of the following options:
. Used to allow customer’s debt information submission to the credit bureau agency. Available if a corresponding setting is enabled for the merchant (Merchant perspective=> Detail => Billing => Settings => Credit Bureau Reporting Status).
Do not report
. Used to blocking out customer’s debt information submission to the credit bureau agency, for example, if a customer is a bankrupt and further debt offsetting attempts are likely to be unsuccessful.
Credit agency dispute
. If a debt matter is being resolved legally (for example, a customer can dispute a debt or is bankrupt), a respective status has to be set.
. A customer may prefer not to be reached via a particular communication tool. The agent can indicate which tool is undesirable to interact with the customer.
Skip trace allowed
. A customer’s contact information can be automatically updated via a skip tracing service provider. To allow for this, the Skip Trace Allowed checkbox has to be activated.
. An agent can modify existing letter templates. Templates have fields of two types - required (for example, address or subject) and optional (footer, secondary title). Only required parameters are subject to editing.
. If there is a need to write an email and perhaps postpone sending it, the agent can use this user interface form. It makes it possible to either simply write an email or assign a certain template to it.
The mechanism works as follows:
1. A debt is formed when a customer stops making payments according to their payment plan. A payment plan can be of two types: fixed and perpetual.
A fixed payment plan means that a certain amount is recovered in equal parts (for example, a payment by installments for goods)
A perpetual payment plan means that a certain amount is paid on an ongoing basis (for example, payment for a gym membership)
If payments on a perpetual payment plan are discontinued by a customer, no debt is formed. If payments on a fixed payment plan are discontinued by a customer, an outstanding amount is considered as a debt.
2. If a debt is formed, the gateway sends up to three notifications on behalf of the merchant to the customer reminding them of the debt.
3. After a certain number of day specified as a collections period (for example, in 100 days after a debt was formed), the system marks that the information on the debt is subject to being sent to the collections bureau agency and the customer is switched to the external collections mode. Additionally to the debt data, the information about the payment plan, which was discontinued by the customer, is sent to the collections bureau agency.
4. When a customer is switched to the external collections mode, new payment plans and payments associated with the payment plan cannot be created.
5. The information on the status of debt recovery is sent to the collections bureau agency once per month until the customer pays it off.
6. A merchant and a customer can come to a debt restructuring agreement and split a debt amount into parts in order to recover it. For this purpose, the Scheduled Payments section can be used.
UniPay - Payment Gateway Software
All Logos and Trademarks used or mentioned on this page are copyrighted property of their respective owners and are used for display purposes only.