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.

Encrypted MSRs and Payment Terminals

The purpose of this article is to analyze card-present transaction processing in greater detail and see how traditional and encrypted magnetic stripe readers (MSRs) as well as payment terminals are used, as well as to explain how MSR or terminal can, potentially, take an application, relying on it, out of PCI scope.

Generally, every credit card payment transaction can be classified as either card-present or card-not-present (CNP) one. Card-present transactions usually involve usage of a physical card, and, thus, a swipe of a magnetic stripe, which requires usage of a special device, called magnetic stripe reader (MSR). Card not present transactions include online and over-the-phone transactions where card information is manually keyed.

From traditional to encrypted MSRs

Traditional MSRs

Initially, traditional MSRs were introduced to read credit card swipes. After a card was swiped, the card data was transferred to the merchant’s payment processing application. The application, in its turn, generated the message for the payment gateway or underlying payment processing system, which would then process the transaction and respond with either approval or decline. Consequently, the swipe data from the card’s magnetic stripe (known as track data) was passed through the merchant’s payment processing application.

With the development of software industry new needs emerged. These were the needs for wider payment processing functionality within larger applications specialized to service a specific market such as restaurant software, supermarket POS, health club management software, country club management software etc.

In other words, if initially, specialized terminals were designed exclusively for payment processing, later the need for an integrated solution emerged. The solution had to incorporate payment processing functionality, but, at the same time, it had to be specialized for a certain industry.

As business software packages became more and more complex, they had to incorporate many additional functions beside basic payment processing functionality. Since software package was involved in communication with the payment gateway, and, therefore, had access to credit card information, it was getting within PCI scope. Consequently, it required PCI audit (generally, a complex and expensive procedure). It was necessary to somehow reduce or eliminate the need for PCI audit of the software which was not directly involved in the processing of credit cards.

For card-not-present transactions the problem was solved by the introduction of payment pages. While payment pages allowed merchants to resolve the issue of getting most of their web-based applications out of PCI scope, for desktop applications (and web applications, for which usage of payment pages was not feasible or desirable) the issue of PCI scope reduction remained relevant.

Encrypted MSRs

One of the solutions of the above-mentioned problem became available with the introduction of encrypted MSRs. An encrypted MSR functions just as an unencrypted (traditional) MSR. The only difference is that card data is encrypted at the point of swiping, using the encryption key injected in the device. The decryption key (to decrypt the data) is only available to the payment application, which will eventually handle this transaction and is not available to the software package that the merchant uses to run its business. Consequently, only the PSP’s payment application (which does have the encryption key) is capable of decrypting the swipe. So, when the swipe is read, neither the merchant, nor the business-specific software application, are able to decrypt it. Thus, only the payment gateway remains within the PCI scope (but PCI-compliance is a standard requirement for any payment gateway).

However, encrypted MSRs do not address one subset of scenarios, which, while minor, still represents a sizable number of transactions for retail businesses. Particularly, sometimes a card may be unreadable, so that the need for keyed entry arises. The card number, its expiration date and other data for a transaction has to be input manually in some way. Therefore, a business software package relying on MSRs cannot stay entirely out of PCI scope.

To avoid abovementioned scenarios and to enhance the way of dealing with credit card transactions in retail industry, payment terminals are used.

Payment Terminals and Their Types

Unlike a reader, which is a peripheral hardware device, a terminal is a mini-computer, specifically designed to facilitate card-present payment processing. It has its own operating system, which can run applications within itself. It has its own network card and can communicate with external systems, such as payment servers, directly. Consequently, it has the ability to establish a data flow of its own between itself and a payment application, which is not going to involve the software application that controls it.

There are several advantages that terminals have over MSRs. On one hand, a terminal allows a business to accept card swipes, while on the other hand, more advanced terminals allow for keyed entry of credit card data, PIN-based transactions and supplementary functionality, such as ability to round up change for charity donations, tip adjustments, customer satisfaction surveys, etc.

Payment terminals are generally classified as standalone terminals and attached terminals {http://global.verifone.com/}.

A standalone terminal has no API or DLL of any type through which an external application can communicate with it. It is mostly used by smaller businesses that use terminals simply to process payments. These businesses, generally, either do not rely on any software package to run their business, or use manual process to reconcile all the payments. Example of such a business is a small restaurant that handles orders on paper and just needs a way to accept credit card payments from customers.

An attached terminal has an API or a DLL that allows an external software application to interact with it. Consequently, attached terminals are generally used by those businesses that rely on some software package for their day-to-day business activities. Example of a business using an attached terminal is a supermarket where payment terminals need to be integrated with the main POS application.

Attached terminals provide a unique advantage to applications that rely on them. A business application is able to initialize the transaction providing terminal with the amount as well as various details (such as item listing, which can be displayed on the screen) through the API. After that the terminal captures the credit card information (either swiped or keyed) or PIN (when applicable) and sends it to the payment gateway, gets a response (approval or decline) and forwards the response back to the business application, without exposing cardholder data to the application itself.


Terminals are ideally suited for purely retail businesses that do not utilize recurring payments in any way, because, in most cases, these businesses do not have any provision for cardholder data flow from the system to the payment service processor (within the context of their application). Those businesses, that (in conjunction with their retail operations) utilize some type of e-commerce functionality and potential recurring billing, can use a combination of terminals, payment pages and tokenization techniques in order to be able to process transactions (accept payments) of various types, but still remain outside of PCI scope.

In cases when payment pages are a suitable option and the cost of terminals (which are more expensive than MSRs) is a major concern for a business, the preference may be given to encrypted MSRs. The only thing to be kept in mind in such cases is that MSRs do not support PIN-debit and EMV card processing on their own.

What is credit card tokenization?

What is credit card tokenization and payment tokenization?

Credit card tokenization is an approach used by businesses, which process credit card payments, to reduce their PCI scope. In order to ensure cardholder data protection, PCI requires credit card numbers to be handled in a special way. Basically, the more contact with actual credit card numbers your payment system has, the higher your PCI scope is, and, consequently, you have undergo the more extensive annual PCI audit. Credit card tokenization service allows merchants to reduce their PCI scope by replacing real credit card numbers with tokens, which are generated using special hashing (and other) algorithms. The actual card numbers card numbers are stored by tokenization service provider, and not by the merchant, so if the merchant’s the system is ever compromised, the card numbers cannot be stolen. The term “credit card tokenization” is more accurate than “payment tokenization”, because it is card number that is actually replaced by a token.

How can credit card tokenization be implemented?

From conceptual viewpoint, there are two approaches to credit card tokenization. They can be called pure tokenization and customer profiling. Under the first credit card tokenization approach only the customer’s credit card number is tokenized when a transaction is processed. Under the second approach the whole profile of a customer is maintained and when a transaction is processed, all the data (card expiration date, billing address) which is necessary for the transaction to come through, is “pulled” from that profile.
From hardware viewpoint, there are also two approaches to credit card tokenization implementation. They are: tokenization through appliance and tokenization as service. Under the first approach the company needs a special PCI-compliant hardware device, to perform tokenization. Under the second approach credit card tokenization service is delegated to the payment gateway, credit card processor, or some third party. The second approach (credit card tokenization as service) can actually get the merchant out of PCI scope, although it requires more integration-related efforts. More information on credit card tokenization and its implementation can be found here .

Becoming a Payment Service Provider

The purpose of this entry is to review the key elements which a business needs to consider to become a payment service provider.

Many ISOs and payment service providers after several years of operations realize that they can significantly reduce their costs and optimize their processing if they rely on their own payment management platform.

However, taking everything in-house may be a challenging process because of the complexity, associated with payment processing and PCI compliance.

In this article we are going to cover the essential components of the process and the challenges of getting your own payment gateway.

Payment gateway software selection

First of all, a business wanting to have its own payment gateway solution (white-labeled or exclusive) will need some payment gateway software.

The options might be to build some software in-house, to buy some connectors and integrate them into an existing customer management product, or to license an already existing payment gateway software. When it comes to existing payment gateway software, the two common options are: to license the software and self-host it or to use a hosted version. For more information, see articles on payment processing solutions and payment gateway solutions on our blog.

The next step in the process is to decide on PCI environment where the payment gateway software is going to reside.

Payment service provider hosting

To become an independent payment service provider, a business can either implement its own server infrastructure or use a PCI-compliant hosting (such as firehost or rackspace).

Self-hosted server infrastructure implies maintenance of a data center, availability of development personnel and annual PCI-audit. PCI-compliant hosting, on the other hand, works in the same way that a general VPS hosting (thus eliminating the need for data center and network engineers), except that the servers are located within an already PCI-compliant network.

Because of the additional PCI requirements, servers at PCI-compliant hosting are more expensive than an equivalent configuration in a non-PCI-compliant environment.

PCI compliance and card storage

An important consideration the business needs to take into account on the way to becoming a payment service provider is PCI compliance. The business will need to find the suitable PCI-auditor company, determine the scope of PCI-audit and request quotes from the preferred service provider (assessor). Examples of possible partners include security metrics and coalfire .

One of the challenges to overcome within the context of PCI-audit is the strategy for credit card storage. If you consider using some form of appliance-based tokenization, the cost of the appliance needs to be factored into the overall estimate. For additional information on tokenization (either through appliance of as service), check the respective article on our blog.

Selection of banks and processors

The final issue to be addressed is the selection of banks and\or processors which will be actually processing transactions.

In some cases becoming a payment service provider will require integration with other payment gateways, credit card processors and\or banks. In case you decide to license a payment gateway software from a third party, it is always a good idea to check what types of integrations they already have.

When evaluating the scope of potential integration efforts, consider these guidelines.

  • Integrations with payment gateways tend to be easy and usually do not require time-consuming certification process.
  • Integrations with banks are, generally, not complicated, and smaller in scope than credit card integrations, but some community banks may not have the technology, advanced enough to enable full automation of the processing.
  • Integrations with credit card processors can be rather complex, especially, if legacy platforms are involved, and even if the software that you license, already has such an integration, it will still have to be certified under your name and your PCI environment.

Here is an illustrative example of possible costs.


Gateway software license $ 50 000 – 250 000
Tokenization appliance $ 50 000 – 100 000
Annual PCI audit $ 25 000
Monthly PCI hosting fee (average number of servers needed is 4 (2 of them for backup)) $ 2 500 – 3 500
Additional integration with new banks/processors (each) $ 5 000 – 15 000

These estimates provide the basis for calculating the approximate cost of a common payment solution that would be required by an average payment service provider.

Payment Concepts: Credit Card Tokenization

This article belongs to the mini-series providing guidelines for merchants interested in attaining PCI compliance. In this installment we are going to cover the approaches to credit card tokenization and possible solutions that make PCI audit more attainable.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

Credit card tokenization concept

The idea behind tokenization is to delegate credit card storage to the payment gateway or payment processing system, as opposed to business-specific software, such as web-site, online storage or CRM. The main purpose of tokenization is to allow merchants not to store credit card numbers for repeated\recurring transactions. To achieve this, credit card numbers are replaced by tokens which are saved and used instead.

Fundamentally, there are two primary approaches to tokenization.

Approaches to credit card tokenization as a process

The two conceptual ways to implement credit card tokenization are commonly referred to as pure tokenization and profiling.

Pure tokenization

Under pure tokenization approach, only credit card (bank account) number is tokenized. However, if necessary, routing number (identifying the branch of the bank) for ACH, social security number, or even driver license number, could be tokenized as well. To put it simply, every sensitive value is replaced by a token (one for one).

When the credit card processing request is issued (during repeat\recurring transactions), the token is used instead of a credit card number, allowing merchants to avoid credit card storage.


The second approach to credit card tokenization (profiling) is a bit more elaborate, as it involves maintaining the full or partial customer profile.

The difference is that in this case the entire billing information, including the billing address, shipping address etc (depending on the system used) would be stored in the customer profile (including credit card number). When a transaction is processed, the ID of the profile is sent, and any fields that are not supplied, are “pulled” from that customer profile.

Some systems use a variation of customer profiles where instead of customer profile an ID of the previous transaction is passed and all of the missing information, such as credit card number etc, is extracted from that transaction.

When repeated\recurring credit card transaction is processed, the profile ID (or ID of the previous transaction) is used in place of the actual credit card number, thereby allowing the merchant to avoid persistence of the credit card number.

Advantage of the first approach is that the business doesn’t have to do any separate maintenance of the profile. It only has one number and the token just replaces it. Advantage of the second approach is that more information can be stored outside of the merchant’s system (web-site\CRM). Consequently, if the merchant has some basic front-end system and doesn’t wish to store all the billing information (ZIP code etc), it can rely on tokenization provider to store that information, which might be more convenient for the merchant. However, with this approach the merchant assumes the responsibility for keeping the profile up to date.

Now let us look at the most common ways to implement credit card tokenization.

Credit card tokenization through appliance

Tokenization through appliance is intended for the pure tokenization approach, described above.

The appliance is a combination of a hardware device (used to encrypt\decrypt credit card numbers) and PA-DSS-compliant software (used to store encrypted values and to generate tokens). The hardware device is usually either a chip on the motherboard or a PCI-card. The appliance (hardware with software written on top of it) is hosted in local network of the merchant\PSP.

Hardware\appliance solution does not eliminate the need for PCI-compliance certification, but it definitely reduces the scope and simplifies the PCI audit, as the storage is delegated to an already PA-DSS-compliant piece of software.

Credit card tokenization through appliance can be an ideal solution for a merchants\PSPs processing large volumes of transactions and already having an existing PCI environment where the appliance could be deployed.

Credit card tokenization as service

The other approach is hosted tokenization service, where, instead of having some type of device in merchant’s own network, the merchant is delegating storage to some other (third) party. In this case the merchant must use some form of API to generate the tokens.

When it comes to credit card tokenization as service, there are 3 conceptually different approaches with minor technical distinctions, nevertheless, important and worth noting:

  • Processor-integrated tokenization – tokenization is an integrated service of the payment processor. The advantage is that the merchant only deals with one and the same party for credit card tokenization and processing. In order to process a transaction there is no need to de-tokenize credit cards (or even to “touch” the actual card number, because it is stored by the underlying processor). If a token is already obtained by the merchant, when transaction is processed, the merchant simply passes this token to the processor and the processor is able to locate the respective credit card number. Under this approach switching to another processor would result in costly data extraction and re-location procedures. And data extraction fees are sometimes really heavy.
  • Gateway-integrated tokenization – the approach is similar to processor-integrated tokenization, except that tokenization is handled by and independent gateway (possibly, servicing several processors). The advantage of this approach is that if a merchant switches from one processor to another (serviced by the same gateway) the tokenization procedure remains the same and costly re-tokenization process is not required. Under this approach the merchant does not touch the card data, remaining completely out of PCI scope.
  • Third party tokenization – cards are stored by the by the third party separate from the one who processes transactions. The merchant uses the API to tokenize/detokenize cards on demand. This option is a little less secure, because although the merchant doesn’t store card number, before it processes the transaction, it has to de-tokenize the transaction, take the actual number and send it to the processor. The merchant is touching but not storing the card number. So, this solution reduces the merchant’s PCI scope, but does not take the merchant out of it.

The next and concluding post in this mini-series will cover payment card data flow and respective solutions allowing merchants to reduce or even get out of PCI scope.