From Batch to Retail Payment Processing


The landscape of modern payment services market is rapidly changing. More and more well established companies, using legacy software, face the problem of expansion of their existing offerings to accommodate the newer needs of the market. One of transition-related issues is the addition of retail functionality to an existing recurring-billing-oriented payment system.


A well established business, which traditionally functioned as payment aggregator, has recently become a payment facilitator. Its main function is aggregation and facilitation of recurring payments in some industry (membership dues, insurance, installment payments, utility bills etc). Now the company faces the necessity to add a card-present EMV solution to its business offering.


The problem is most relevant to billing companies, which sell their software products to front-end users. Many of such billing software vendors traditionally focused only on card-not-present transactions. They used to function as recurring payment aggregators for a long time, but (under pressure from associations) switch to payment facilitator model. We should remind, that such a transition also allows these companies to get greater control of merchant underwriting process.
On the other hand, under pressure from their customers, they have to add retail component as well as e-commerce processing to their (initially recurring-payment-oriented) payment system.

The pressure from the customers has the following reasons.

Many customers of such companies are brick-and-mortar businesses, which emerged long before online operations became possible. (Recently founded businesses, in contrast to brick-and-mortar ones, operate mostly online and, consequently, do not need any retail components). Some other businesses, representing the clientele of recurring payment aggregators, follow “mixed” operation modes.


A fitness center receives membership dues as recurring online payments, but sells physical merchandise, such as apparel, foods, drinks, and supplements, at a physical facility. Another example is an insurance company, which collects recurring payments, but wants to be able to collect past due payments and pre-payments in retail environment or online.

In order to be able to accept card-present/EMV payments, some of subscription-based businesses resort to third-party solutions, such as usage of standalone payment terminals. For handling of online payments these businesses can use PayPal or services on an individual basis. However, we should stress, that reconciliation process becomes more complex, as you, potentially, have to reconcile payments handled by multiple systems.

Another issue, faced by recurring billing companies, concerns handling of non-recurring payments. All the payments, made using a standalone terminal (past due payments or pre-payments, for example), have to be, then, manually input into the primary system of record, used for management of recurring payments.

Consequently, in order to ensure greater convenience and flexibility of operations for its customers, the aggregator/payment facilitator has to add both retail and e-commerce processing functionality.

Addition of a retail component, in fact, calls for implementation of real-time processing functionality. As EMV has recently become an official standard for retail payment processing, in a situation like the one just described, implementation of EMV solution becomes a top priority.

In order for your retail payment processing implementation project to be a success, you can use the following strategy, which includes several important steps, and which poses some challenging questions to be answered.

Strategy in brief

You need to understand both business and technological sides of the problem.

Business-related questions are as follows.

  • How are merchant accounts going to be issued? Who will be underwriting them?
  • Which processing system is going to be used?
  • What is the integration cost and how much time will the integration take?
  • What’s going to be the by-rate charged by processor for retail payment processing and what rate will be charged for the merchants?
  • How will funding be handled?
  • How will merchants acquire the necessary equipment? Who will they buy payment terminals from? Is fulfillment center relationship needed? How the terminals are going to be priced (full price/discounts/subsidies)?
  • Which card brands are you going to handle and in which countries?

Technology-related questions are as follows.

  • How you are going to implement a payment terminal solution and go through EMV certification, if necessary?
  • Which architectural changes need to be introduced into the existing system, initially developed exclusively for handling of recurring payments, in order to enable it to support real-time payments?
  • Are you going to use standalone terminals, or do you need to integrate with some POS systems?
  • Will you need only standard terminals or mobile terminals as well?

Strategy in detail

Here (in greater detail) are some important strategic issues to address.

Who will provide merchant accounts for retail payment processing?

Can you stay with your current processor? If your current processor supports different payment modes, such as e-commerce and EMV, can you use them for both recurring and retail payments? If yes, can you provide retail (real-time processing) services as a payment facilitator (the model you are already successfully using for batch processing), or do you need to switch to a different model (say, a retail ISO) to provide retail services? As we explained in our previous articles, under retail ISO model, you will simply resell merchant accounts, while merchant on-boarding and funding will be handled by the processor. If you stick to the payment facilitator model, you will have to handle merchant on-boarding and funding.

If your current processor is CNP-only, should you try to establish a new retail relationship? I.e., should you try to get merchant accounts for retail from a different processor? Does it make sense to move your entire business (both card present and CNP) to the processor that offers all the functionality you need, a better price, and, possibly, some additional services (such as robust merchant on-boarding, chargeback handling, and cross-brand account updater mechanisms)?

How are you going to technologically implement the integration?

Real-time and batch integrations are conceptually different processes. Consequently, no matter, whether you switch to a new processor or stay with the current one, real-rime integration is needed anyway. Moreover, if you need to use EMV payment terminals or mobile devices, you also need to select an appropriate EMV solution. As we mentioned in our previous use case, you have to study hardware options, supported by your specific processors, and, if you want to use your own customized terminal solution, you have to keep in mind fulfillment-related issues.

During the integration, you can either develop the software using your own development team, or use some third-party software product.

How are you going to handle non-recurring payments?

Your existing recurring billing system is, most probably, not adapted for handling of one-time payments. If, conceptually (and architecturally) the system was not intended for support of one-time payments, then addition of non-recurring payment functionality is quite a challenge.

Even if you have the logic to handle one-time cash or check payments, this logic might be too rudimentary to accommodate real-time credit card or ACH processing. Moreover, this functionality is, probably, not fit for handling of complex transaction lifecycles.


Addition of a retail payment processing component to your recurring-payment-centered system can be a major challenge, given all of the items that you have to consider. However, you can consider this challenge as an opportunity to switch to a more standardized and robust payment management platform (such as UniPay Gateway), that will not only solve the current problem, but also improve the overall quality and the capabilities of your existing payment ecosystem.

How to decrease transaction decline rate in recurring billing?

How to reduce the number of credit card transaction declines in recurring billing environment?

There are many common reasons behind soft declines and hard declines. Many payment declines result from the fact that either expiration date or credit card number specified during the initial transaction submission is invalid. Respective transaction decline codes (“invalid expiration date” or “invalid credit card number”) are generated by the host payment system. In case of “invalid card number” the specific reason behind the decline must be verified with the cardholder. “Invalid expiration date” response means that either the card really expired, or the expiration date specified during transaction submission and the expiration date on the card are not the same.

In some cases usage of recurring indicator might increase approval rates.

What is a ‘recurring’ indicator?

A recurring indicator is a special ‘flag’, which marks the transaction as a recurring one.

If a processed transaction is a recurring one, it should be marked with a recurring indicator. If a recurring transaction is marked with the indicator, most issuers might still approve it even if card\account expiration date is in the past.

In other words, if during some billing period the ‘invalid expiration date’ response is received by the submitter, but it is recorded that recurring payments from the card were successfully coming through during previous recurrence periods (there is a previous processing history), the transaction, bearing the ‘recurring’ indicator, might still be processed.

What is an account updater? How can credit card account updater improve approval rates?

Account updater is a service offered by issuing banks through acquirers, which allows to get updated information on a particular card of the issuer. The information can include updated holder name (if there’s been a name change), updated expiration date, updated account number (if account number has been changed due to fraud, or because card has been lost\stolen).

Account updater is a handy tool in recurring billing environment, where usage of the most up-to-date payment information can eliminate potential declines caused by invalid card numbers, or expired credit cards.

4 Cs of Recurring Billing

The purpose of this article is to explain the key mechanisms a business must put in place to implement a coherent recurring billing solution. While in one of our previous articles we described the 3 Cs (creation, conveyance and collections) from a general transaction processing perspective, in this post we are going to focus on recurring billing processing and define 4 Cs of a recurring billing solution.

Each of the Cs reflects a certain aspect of recurring payment processing.


As we mentioned in the article on 3 Cs, creation of payments is associated with a system, from which these payments originate. The key elements around the creation phase of a recurring billing solution are:

  • Subscription Types. Subscription types reflect various service and product options offered by the merchant.
  • Payment Plans. Payment plans reflect specific payment arrangements (frequency of payments’ recurrence etc)
  • Payment Methods. Payment methods include electronic form of payment to be used in recurring billing process
  • Payment Page Security. This aspect incorporates means for capturing and secure processing of cardholder data. Detailed information on payment pages can be found in the respective article.


It has been mentioned that compliance is a critical issue in recurring billing context, as recurring billing requires cardholder data to be stored somewhere in order for subscription-based business to be able to access it at regular intervals, when the actual billing takes place. Detailed information on PCI compliance requirements can be found in the respective article. The items to consider in the context of compliance are:

  • Card Data Storage (who is going to store cardholder data and how it will be stored). Cardholder data storage options are described in the respective article of our blog
  • Tokenization. One of the most common solutions for PCI compliance is tokenization. As we described in our respective post, tokenization is a flexible mechanism allowing companies to reduce their PCI scope or even get out of it completely, while still being able to process recurring transactions. The company must decide, how to implement tokenization in order to make PCI audit as smooth as possible
  • Data Ownership. The inherent problem of tokenization is the ownership of cardholder data. Ownership (and, particularly, change of ownership) of cardholder data is a tricky matter, especially, when it comes to third-party tokenization. If the company uses tokenization services, provided by some external entity, and wants to switch to another tokenization services provider, the original provider might claim the ownership of cardholder data and refuse to handle it to the new provider. In order to avoid situations like this one, data ownership and related matters must be taken care of and agreed upon in advance


As we mentioned in the article on 3 Cs conveyance of payments concerns relationship with payment gateways through which transactions will be submitted to the processor. Conveyance of payments calls for implementation of the following important aspects and relationships in the recurring billing system:

  • Soft Descriptors. Implementation of soft or dynamic descriptors is an important issue, particularly in recurring billing context. The soft descriptors allow customers who have multiple subscriptions (or those who subscribed to a service a month ago) to recall which particular subscription they are charged for, when the statement arrives. Soft descriptors are also an essential feature to be implemented by companies, using aggregation model, as they include the descriptions of the aggregator, the merchant, and the transaction itself. In all described cases implementation of soft descriptors allow companies to avoid chargebacks, erroneously issued by customers
  • PSPs, Acquirers. The company needs to decide, who is going to underwrite its own merchant account or merchant accounts of other businesses that it will be servicing. Respective relationships with PSPs and acquirers must be established, taking into consideration not only pricing, but also the need for different currencies and overall feature set.
  • Gateways. If a company decides to use a payment gateway, it needs to carefully consider the choice of a particular payment gateway solution (hosted, licensed or in-house), which is most suitable for the company’s business model.
  • Direct-to-Processor. Usage of hosted gateways is undesirable when a direct-to-processor integration is necessary. In this case the company needs to find some licensable payment gateway software that can be used to simplify the integration process
  • Hybrid. If the company needs a combination of gateway and direct-to-processor integrations, it also has to implement the optimal (in terms of value-for-money) combination of the respective approaches


Collections of payments calls for implementation of the following items:

  • Reconciliation. Even in the most basic processing scenarios (for example, a gateway for credit cards and a bank for ACH) the entire process of reconciliation (matching of what was processed to what was received as a deposit from the processor) needs to be thought through. The company should implement the most flexible and transparent reconciliation mechanism
  • Decline Management. Decline handling is of particular importance for recurring billing, because if transaction declines, future recurring billings may not be possible. At the same time, contacting cardholder all the time is an expensive process. Some type of retrying\recycling\rebilling mechanism should be defined and implemented beforehand to minimize interactions with the customer.
  • Credit Card Updater. A typical reason for a decline is outdated credit card information (expired card). A common solution to this problem is implementation of credit card updater functionality (described in the respective article on decline recycling) as part of the decline recycling process
  • Customer Communication. No matter how good your decline recycling mechanism might be, some contact with the customer is still unavoidable. Therefore, it is essential to think through the customer communication process and the rules that the agents will follow as they call upon customers trying to collect declined transactions
  • Dunning Management. In some cases communication with a customer proves to be ineffective and debt has to be collected in some other way, be it through additional calls or e-mails, or via some third-party collections company. Some companies might prefer to drop the account and terminate the service while others may engage the services of a third-party collections company to still collect the debt. It is advisable to define collections strategy before getting the actual subscribers. In our respective article collections process is described in greater detail
  • Charge Back Management. In order to preserve its good reputation and avoid getting into the Terminated Merchant File (TMF), any company must keep the number of chargebacks issued by its customers at the minimum. In some cases even detailed soft (dynamic) descriptors are insufficient. Therefore, the company needs specific mechanisms to obtain chargeback information as soon as it is available, as well as to have a process to respond to inquiries and dispute chargebacks (these matters are addressed in the respective article).


In order to implement recurring billing it is not sufficient for a company to just find some recurring payment platform, which will regularly charge certain amounts from the clients. All aspects regarding creation, compliance, conveyance, and collections, must be taken care of in advance. Consequently, all technical features must be analyzed, appropriate business relationships (for underwriting etc.) should be established, and all processes around decline recycling and payment collection should be defined.

What is a recurring billing?

What is the difference between committed and uncommitted recurring billing?

Recurring billing is a process when a merchant charges a customer’s account at regular time intervals for purchases of goods and services. Uncommitted recurring billing does not involve any minimum number of required payments, while under committed billing a customer is required to do a specific number of payments. Under committed billing, if a payment is missed, and account becomes delinquent, the creditor (a subscription-based business using recurring billing system) generally attempts to collect any past dues.

What payment schedule types are available for subscription-based businesses?

The three recurring billing schedule (or payment plan) types are:
• fixed plan (when a limited number of payments are charged at regular time intervals),
• unlimited plan (when the number of payments is unlimited, and they recur until being cancelled by the customer),
• hybrid plan (when after a certain period of time a fixed plan becomes an unlimited one). More information on the subject can be found here.

What is the difference between repeat billing and recurring billing?

Under repeat billing no outstanding balances and past dues are accumulated, while under recurring billing the amounts owed by the customer are accumulated and stored in order to facilitate further collections attempts. An online dating web-site subscription is a typical example of repeat billing, while a typical example of recurring billing is a two-year-commitment on a cell phone plan. Consequently, the second approach is more complex in terms of recurring payment processing. More information on the subject can be found here.

How is credit card data handled during recurring payment processing?

If a business, using some recurring billing solutions, stores the actual credit card data, it falls within PCI scope and has to undergo the costly PCI audit procedure. The two techniques, allowing merchants to reduce their PCI scope or even get out of it, are credit card tokenization and profiling. More information on the subject can be found here.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

Collections Process

If you haven’t read the introductory article to recurring billing mini-series, as well as the article on basic and advanced recurring payment features, you are welcome to do so, as it will improve your understanding of the current post.

Collections process is an attempt to recover a declined payment or an outstanding debt.

When a business deals with committed recurring billing model (described in the previous article), there is a follow-up process performed for recovery of unpaid balance. It is quite important to think through how the follow-up process is going to happen on declined payments, and, therefore, make sure that this feature is taken into account when a specific system is chosen.

If there is a necessity to collect a declined payment or an outstanding debt, depending on the particular account and situation, one of the 3 approaches can be utilized. The 3 approaches, often referred to as re-bill process, first-party collections and third-party collections, are as follows.

Re-bill process

In general, the re-bill process is a reattempt of a previously declined transaction. Re-bill process can be combined with decline recycling); in fact it is similar to declined credit card transaction recycling, but in case of rebilling the reattempt can be made a month later with additional late or decline fees included in the transaction.

There are several methodologies that businesses use for rebilling, and, depending on the methodology, you might want to go with a system capable of accommodating it.

Re-bill methodologies

Let us say, a person owed a company $50, during the previous month his $50 payment were declined, decline and late fees, which are due, amount to $25, and current month’s debt constitutes $40.

The re-billing methodologies are listed below.

  • The first and the simplest strategy is to charge the monthly amount which is due, and collect everything else manually, through first-party collection process (see next section).

    Under this strategy only the sum of $40 which is due this month will be collected from a person in the abovementioned example.

    While the approach is most commonly used within the context of committed billing and term agreements, it is also applicable to non-committed billing, even for charitable organizations, such as churches. For example, a card may get stolen, and the cardholder forgets to tell the charity the new card number.

  • Under the second strategy, if previous month declined, the business would reattempt whatever is due this month plus previous month, plus any service fees.
  • If we return to the abovementioned example, under this strategy the business will try to collect $40 for the present month, $50 for the previous month and $25 of accumulated fees.

  • Under the third strategy, on a due date the entire outstanding balance is collected.
  • If we return to the abovementioned example, under this strategy the business will try to collect $50 of the original debt, $40 for the present month, $50 for the previous month and $25 of accumulated fees.

Sometimes people use a hybrid model, where on the due date they are going to collect whatever is due this month, and, if the payment is successful, they are going to try to collect the entire outstanding balance, on some other date, towards the end of the month.

First-party collections

First-party collections is a process when a call is made to person in order to recover a payment and get updated payment information. During the first-party collections phase an e-mail or a printed letter is sent, notifying of a declined payment, and a follow-up call is made by a company representative. When the call is made, a representative introduces him or herself to the person as an employee as an employee of the original debtor\merchant\business (even if the process is outsourced and the caller actually works for a different company).

First-party collections process runs in the name of the original merchant or the billing company. It is done by the representatives and under the name of the business that the customer signed original agreement with.

The primary purpose of first-party collections is to recover the declined payment. Usually, the goal of first-party collections is to recover declined payments within the first 90 days from the decline date. Beyond that term third-party collections process is started (see next section).

Third-party collections

Third-party collections are usually done on outstanding debt which is more than 90 days old. In third-party collections process when the call is made, the caller introduces him or herself as a representative of a collection agency, and not of the original business, the customer signed the agreement with.

Normally, businesses, that do not have third-party collections licenses in a given state, are not allowed to use third-party collections techniques, such as credit bureau reporting. Only certified collection agencies have the authority to report customers to credit bureaus.

Overall, third-party collection process tends to be more aggressive, because in many cases accounts are considered unrecoverable, and the primary goal is simply to collect as much of the outstanding debt as possible, while in the first-party collections the primary intent is not only to recover the funds, but also get the customer to continue using the service.

Third-party collections process is more formal and structured than first-party collections. It usually involves 3 to 4 formal collection letters, sent out every 30 days. Beside that, the collections company can make a certain number of calls. After that it is allowed to report the account to credit bureaus.

During third-party collections certain data about the customer may be obtained by a collections company in order to maximize the chances of collecting. The process is often referred to as data scrubbing.

The process of data scrubbing, often used in the third-party collections, involves several techniques listed below.

  • Skip-tracing – verification of updated contact information, such as alternative phone numbers and mailing addresses to locate the person;
  • Bankruptcy scrubbing – verification whether the customer has formally filed bankruptcy and is under the bankruptcy protection (thus, no collection calls are allowed);
  • Verification if the person is alive

By this article we conclude the series of installments dedicated to recurring billing. The next topic we are going to cover at is merchant services commission sharing.

Important Recurring Billing Features

In the previous article we described recurring payment types and payment schedules. In this one we will focus on specific recurring billing features and provide examples to illustrate how these features work.

More and more present-day businesses use recurring payments as the foundation of revenue model for their business. In recent years recurring payment industry has grown significantly. As it matured, it defined several features that are common and more or less standard for recurring payment solutions.
Availability of these features within a payment system makes recurring billing process more flexible and smooth for a business.

Freezing of a payment plan

Payment plan freeze is an ability to pause recurring billing schedule for one or more billing periods.


A person has a health club membership; he is going abroad for a business travel or vacation and is unable to use the facility for the entire month. Thus, a freeze is necessary to skip one month’s billing. In cases like this one, payment plan freeze is an essential feature of recurring billing process.

Deferment of payment plan

Payment plan deferment is an ability to defer the first billing date of a payment plan.


A business comes out with a promotional offer: “Pay $50 now and nothing for the next 3 months!” or “Pay $50 for the first 3 months and only $25 every month after that!” In such cases, at the time of signing the customer has the ability to defer the billing for the next 3 months.

Variable payment amount

This recurring billing feature determines the ability to specify different amounts based on a payment’s sequence number.


A common example would be a promotional offer where first three payments are half-price. Let us say, a business offers first 3 months of service at $25 a month and remaining months – at $50 per month.

Ability to change billing dates

Subscription-based businesses rarely change recurrence frequencies (for instance, monthly payments cannot suddenly be replaced by weekly payments). However, some clients like to realign their billing dates to make it easier to track their expenses.


A person originally signed up for the service on the 20th of the month (and is thus billed every 20th of the month). However, the person is paid by his employer on the 5th, and he would like his recurring payments to come out right after that on the 6th of the month.

Advance cancellation (Future cancellation)

There can be two ways to cancel a subscription. Either cancellation can be effective the very day or it can become effective at some point in the future. While most businesses allow immediate cancellations, some businesses require support for future cancellations, as certain customers might like to cancel their subscription to a service in advance and continue to use the service several weeks after the cancellation request was made.


A promotional offer lasts for 12 months, while in month 13 the price of the service increases, so the customer can arrange the service to be terminated after the first 12 months. Cancellation of an agreement requires physical presence of the customer at the facility. If the customer feels that he is not going to be around towards the end of the 12th month, he might want to do an advance cancellation several weeks before that. In such a case the ability to cancel the subscription in advance can be a handy option.


Pre-payment is the ability to make a payment against a future recurring payment, so that the future recurring payment doesn’t happen.


A tanning salon customer, who uses a credit card as a regular form of payment, maxed out the monthly credit limit. She knows that the next recurring payment is not going to go through, so she comes in and pre-pays it in cash.

Support for buy-out

This recurring billing feature is applicable to term and roll-over agreements, where there is a commitment to specific number of payments, and the payment plan has an overall fixed value. Some companies, especially those dealing with loans and personal or business credit, may offer an option for an early repayment.


A customer signed a 12-month agreement, at $100 a month; the total value of the agreement is $1,200. However, if this customer is willing to pay in full on the 3rd month, the company may be willing to discount the remaining payments by 15 per cent.

Support for service fees

Service fees under consideration include late fees, decline fees, cancellation fees. In some cases businesses need to surcharge service fees, and it is always convenient when the fees can be preset and automatically applied by the system when a certain event occurs.


For example, if a customer’s card got declined and no payment was made for 15 days, $15 late fee is automatically assessed.

Support for customer alerts and notifications

The feature under consideration means an ability to send out e-mail or printed letter notifications based on some events within recurring billing life-cycle.


Some businesses prefer to notify their customers before the charge occurs. Most businesses need to notify their clients when decline happens or when a card is about to expire and new payment information is required. Some businesses like to send out a welcome letter in which they define the descriptor of the transaction as it is going to appear on the cardholder’s statement.

Automated write-off

When people use uncommitted schedules, unlimited plans or rollover plans in their rollover phase, there is a common practice of automatically writing off the account after several months of unsuccessful billing. The account gets closed and invoices are written off. This recurring billing feature is especially relevant if the outstanding debt is uncollectible (or difficult to collect) and the amount is not significant, so it is not worth trying to collect it.


An example might be a low-cost pay-as-you-go gym membership at $10 a month. After the recurring payment gets declined for 3 months it might be easier for the gym to write it off and deactivate the account than try to get the person to pay the balance.

These were the key recurring billing features to be considered by a subscription-based business while choosing a payment system to integrate with. Subsequent installments will cover such recurring billing aspects as account balancing and collections. Particularly, the next article will describe more advanced recurring billing features, such as accounting methods and account balancing methodologies.

Introduction to Recurring Billing

The purpose of the mini-series of articles we are going to publish is to familiarize businesses with the concept of recurring billing and the most important recurring billing-related features to be considered by a business while choosing a payment system to partner with.

Many people feel that recurring billing is just an ability to charge the same amount every month over and over again, and whichever system can do this for the lowest price, is the one to go with. In reality, the situation is more complicated, because there are various paradigms and specific features that may be required. These features will make recurring billing process extremely easy on one system, and extremely complex and limiting on another.

Subsequent sections will describe various recurring billing aspects and features.

Recurring billing types

There are two recurring billing types which can be defined as committed and uncommitted recurring billing.

  • Uncommitted recurring billing carries no minimum time commitment and requires no special handling in case of delinquency (when the service or subscription just gets discontinued). A common example of uncommitted billing would be a subscription to news or dating web-site
  • In case of committed recurring billing if a payment is missed and an account becomes delinquent, a collection attempt is made to reinstate the account and collect any past due. Simply deactivating the service is not an option in such cases. Examples of committed billing include term gym memberships and cell phone contracts

Types of recurring payments

All recurring payments can be classified as falling into a regular scheduling pattern or an irregular one.

  • Regular payment schedule – recurring payments fall into some regular schedule (weekly, monthly, weekly, quarterly, annually). An example is a gym membership billed every 5th of the month
  • Irregular payment schedule – payments are made on specific, arbitrarily chosen (pre-defined) dates, depending on specific business context. An example is a payment arrangement for debt repayment

When regular payment schedule is followed, the terms of the recurring payment are represented with a payment schedule (also referred to as a payment plan). There are several payment schedule types available.

Payment schedule (or payment plan) types

  • Fixed (term) payment plan – a certain payment amount is agreed upon, and the number of payments is limited (fixed) by the agreement/contract. For example, $1,200 can be paid during a 12-month period at $100 a month
  • Unlimited (pay-as-you-go) payment plan – payment is going to recur until the plan is explicitly cancelled. For example, $40 a month web-site subscription can recur as long as it is not explicitly cancelled by the client
  • Hybrid (rollover or open-ended) payment plan – initially consists of a fixed (defined) number of payments, however, after the initial fixed number of payments, the billing continues to recur (the plan becomes unlimited) until it is explicitly cancelled. For example, 6 monthly payments, $100 each are required, however, the billing continues at $50 per month (after the initial 6 months) as long as the customer desires to use the service.

While regular payment schedule can use any of the three aforementioned payment plan types, irregular payment schedule relies on fixed pre-defined dates only.

Now that recurring billing types and payment plans are described, it is appropriate to move on to specific recurring billing features. The next post will describe essential features, which are typical for recurring billing process.

ACH and Credit Card Transaction Descriptors

The purpose of this article is to familiarize merchants and payment service providers with the concept of ACH and credit card transaction descriptors.

Descriptor definition

A descriptor is a description of a product or service purchased by a customer from a certain merchant that appears on the customer’s statement, explaining a charge (or refund) of the merchant.

Descriptors are fixed in length. For instance, standard credit card transaction descriptor length is 22 characters at most. These, generally, include the DBA name of a merchant and the name of the product/service, separated by asterisk (*) symbol. Some processors also allow to specify telephone number or web-site of a merchant in descriptors; some banks do not display all this information on cardholders’ statements, but most do.

What are descriptors intended for?

A descriptor is designed to remind a customer what the transaction was, and what the money was charged for (in order to avoid groundless chargebacks). Consequently, it is critical for ACH and credit card transaction descriptors to be as informative as possible, especially on recurring billing transactions.

Credit card transaction descriptor configurations

Depending on the processor and the platform, credit card transaction descriptors can be either dynamic or static.

Static descriptors

A static descriptor is associated with the merchant ID. This means that one merchant ID corresponds to one descriptor. All transactions associated with a given merchant ID bear the same descriptor (e.g. look the same on the statement).

Dynamic descriptors

A dynamic descriptor is specified at the transaction level, i.e. different transactions with different descriptors can go through one merchant ID. Even though the same merchant ID is used for all transactions, each transaction can have its own descriptor (verbage).

Dynamic descriptors are the more preferable and flexible option.

Depending on capabilities of a given platform, the information about descriptors can be submitted at different times:

  • Authorization-only – some platforms accept descriptor information at the moment of transaction authorization.
  • Settlement-only – some platforms accept descriptor information at the moment of transaction settlement.
  • Authorization and settlement – some platforms accept descriptor information during both transaction authorization and transaction settlement.

Ability to submit descriptor information during both authorization and settlement is nice, but authorization-only option is sufficient. Settlement-only option is less ideal, so some banks do display transaction description online as soon as the transaction is authorized.

ACH transaction descriptors

Many banks within the US utilize NACHA file format for ACH processing. NACHA format allows to use descriptors in a way similar to the one used for dynamic descriptors. When a file is sent, ACH transactions are grouped into batches, and every batch can have its own unique descriptor, comprised of the merchant name and item description. Although, dynamic descriptor effect can be emulated to some extent, the approach doesn’t really allow to have a unique descriptor of every single transaction processed.

Examples of ACH transaction groups to be marked with unique descriptors are: utility payments, recurring dues, club membership dues, etc.

Descriptors for aggregators and payment service providers

Dynamic ACH and credit card transaction descriptors are particularly important for businesses, that use aggregation model. The reason is that dynamic descriptors allow aggregators and payment service providers to specify which of their merchants originated a given transaction (or batch). In such cases the following descriptor format is used:
[Aggregator name (up to 6 digits)]*[sub-merchant company name]

Here are some common descriptor formats and examples.


[aggregator name]*[sub-merchant company name]
PSP*convenient store NY
ISO*John’s dehli
[Company]*[product name]
Best clothes*jeans black


It is preferable for businesses (especially, for those using subscription-based or aggregation revenue models) to cooperate with credit card processors and payment gateways supporting dynamic descriptors.