3 Cs for Payment Service Providers

The purpose of this article is to explain some essential components and mechanisms needed for a business to become a payment service provider.

With the increased use of electronic payments worldwide, there are more and more companies that are contemplating the idea of becoming payment service providers. However, many people, pondering the idea, lack the conceptual understanding of the essential components of the process that have to be implemented in order for these potential payment service providers to be able to operate.

There are three aspects to the formation of a payment service provider that can be called creation, conveyance and collection each dealing with various types of relationships, namely relationships with future clients (merchants), payment gateway provider(s) and an underwriting banks/processors.


The 1st group of relationships consists of the actual merchants and, in many cases, software vendors, through which the future payment service providers are going to service these merchants.

Basically, creation aspect of the process deals with the systems from which transactions originate. Some software products are necessary to originate transactions (for processing) or subscriptions (for recurring billing).

In case of a payment service provider servicing charities it might be as simple as just a web-site, a single page which will accept credit card donations and pass them on for processing. In the opposite “extreme” case, it can be as complicated and elaborate as an enterprise-scale POS or recurring billing software system.


The 2nd group of relationships involves either a gateway software provider, or a gateway services provider. A gateway software provider is a company that is going to supply gateway software product, while the gateway services company is going to provide the hosted offering for the gateway.

Conveyance of payments is conducted via a payment gateway through which payments are actually delivered from the originating system to the transaction processor.

Usually, PSPs will need to communicate with a multitude of payment processors and banks as well as with a multitude of the originators of the transactions (or, usually, the customers of the PSP – other software companies, POS vendors etc.). Consequently, there is a need a unified API and a unified approach that the originators could use to potentially communicate with a multitude of back-end processing systems.

That is where the need for a payment gateway software, or a payment gateway services provider (a.k.a. payment gateway) comes from.

In addition to gateway software provider, the potential future PSPs will also need to work out the PCI compliance strategy.


Lastly, the 3rd group of relationships will be banking relationships, i.e. banks willing to underwrite merchants and facilitate the process of subsequent merchant funding (settlement).

Collection of the payment is the phase during which the payment is actually processed and the merchant is funded. It requires a relationship with a bank.

Unless a PSP has direct relationships with card associations, it will need to rely on an existing account underwriter, usually a bank. While there are different arrangements around who takes/accepts the underwriting risk, some third party would be required to verify and approve the initial merchant application, and subsequently facilitate actual money transfers that follow settlement of authorized transactions.


While many people, who come from the small-business transaction-processing world tend to see the creation/conveyance/collection system as one complete piece (such as PayPal or Authorize.Net), in reality, there are 3 separate aspects involved, and any business wanting to become a PSP will need to search for solutions specific to each of these aspects.

PCI Compliance Levels

The purpose of this article is to familiarize different merchant services industry players with the four levels of PCI compliance, and briefly describe some solutions available for level 4 merchants (the most common category), allowing them to go through PCI certification procedure as smoothly as possible.

As we mentioned in one of the previous articles, any business dealing with cardholder data in some way, has to meet PCI compliance requirements and go through some sort of PCI audit procedure. Depending on volumes of transactions processed (including online transactions) a business is classified as belonging to one of the four PCI compliance levels. Beside processed transaction volumes, a company’s PCI compliance level also depends on predominant card entry mode the company utilizes. There are several card entry modes (determining card industry types), but in terms of PCI compliance levels card entry modes (or card industries) can be divided into two basic categories: e-commerce and other transactions.

Let us briefly review the levels of PCI compliance (as they are defined by Visa), moving from 4 to 1.

How PCI compliance levels are defined

A level 4 merchant is a business processing less than 20 thousand Visa e-commerce transactions a year, or any merchant processing less than a million Visa transactions a year, regardless of card entry mode.
A level 3 merchant is a business processing between 20 thousand and one million Visa e-commerce transactions a year.
A level 2 merchant is a business processing between 1 and 6 million Visa e-commerce transactions a year.
A level 1 merchant is a business processing more than 6 million Visa e-commerce transactions a year, or a business, considered a level 1 merchant by Visa association itself (based on cardholder data security and risk related considerations).
The complexity of PCI compliance certification and PCI audit for a given business are determined according to the level this business belongs to.

PCI compliance-related solutions

In order to meet PCI compliance requirements, merchants, belonging to PCI compliance levels 1,2 and 3 can utilize various solutions (such as tokenization, profiling and others), enabling them to store credit card data and manage cardholder data flow in the most effective way.

Many online businesses, web-sites, and small size merchants, fall into level 4 category, and often look for the most suitable solutions for PCI certification. In this post we focus on this (most common) type of merchants – level 4 merchants, which, according to some sources, handle about one third of the total volume of credit card transactions processed.

In order to meet PCI requirements, level 4 merchants have to fill out the so-called SAQ (self-assessment questionnaire). The type of a SAQ (ranging from A to D) that a given merchant has to fill out, depends on this merchant’s validation type. Basically, the validation type depends on how the merchant handles cardholder data (and whether the merchant stores it or not). More information on merchant validation types can be found here.

Level 4 merchants often utilize the services of other companies (level 1 service providers acting as PSPs in this case) to process credit cards. Particularly, they often rely on payment pages and tokenization services of the PSPs. In most cases the PSP itself would have a special mechanism for level 4 merchants, simplifying the process of filling out the SAQ significantly.

For example, most companies, performing PCI audit (such as Trustwave, Security metrics, CoalFire) have special software packages (or web-based offerings) designed to help level 1 providers that use them for PCI audits to simplify the completion of the self-assessment questionnaires for their level 4 customers.

Basically, an SAQ is a simple *.pdf document. PCI audit companies create special web-portals for level 4 merchants. An authorized level 4 merchant can enter such a portal, submit its SAQ, and identify its payment service provider. After that the fields related to the PSP are auto-filled. These can be the fields denoting particular features (which level 4 merchants might not even be aware of), provided by the PSP itself and not by level 4 merchants from the PSP’s portfolio.

The described arrangement (solution) greatly simplifies the process of PCI compliance certification for both PSPs and their level 4 clients, as well as for PCI auditors themselves.


Before starting to worry about PCI compliance, a level 4 merchant should reach out to its PSP and enquire about the respective automated solution, that the PSP might already have in pace.

Recurring Billing System Organization

The purpose of this article is to familiarize merchant services industry players, searching for a suitable recurring billing solution, with several conceptual approaches to recurring billing systems implementation, as well as explain advantages and disadvantages of respective solutions. Based on the insights provided in the article below, businesses can make the choice of their recurring billing partners more intelligibly.

As we mentioned in one of the previous articles, there are two basic types of payment plans: term (fixed) plan and open (unlimited, pay-as-you-go) plan. There are also hybrid plans which have a ‘term’ part with an ‘open’ end.

Depending on the predominant type of payment plans a company utilizes, respective features need to be supported by its recurring billing software.

Critical recurring billing system features

The needs of companies using recurring billing systems revolve around several key features which should be considered when a recurring billing system is implemented:

  • Payment plan setup – ability to set up payment plans with relative ease through UI or API
  • Adjustments to existing payment plans – ability to introduce changes in billing dates, implement freezes, billing deferments, cancellations, future cancellations, partial cancellations etc.
  • Revenue forecasting – ability to easily say what the revenue is going to be on a specific date in the future as of today
  • Billing history analysis – ability to analyze billing differences between two or more billing dates (weeks in case of weekly billing, or months in case of monthly billing) in the past
  • Collections process organization – availability of decline recycling and collections functionality within the recurring billing system

For every business some features have higher priority than the others.

If we were to analyze common needs of companies that rely on recurring billing, we can see certain similarities of patterns, based on which, the companies can be organized into at least three groups. The three groups of businesses depending on their needs can be defined as follows: online subscription-based businesses, businesses relying on sales force, and businesses utilizing collections (although some companies can belong to several groups at once).

Company types depending on recurring billing needs

Online subscription-based businesses

Companies of this type exclusively use open payment plans, which bill on the anniversary date of the original subscription (monthly or weekly). If there is a problem with a payment, the service gets suspended (as described in respective article) and little or no collections effort is made.

Another specific feature of purely online subscription-based companies is a limited number of payment plans (i.e. pricing options) they are offering their clients.

The billing needs of these companies are relatively modest. Setup of open payment plans is really simple. Adjustments, other than cancellation, are not common. Forecasting is also relatively simple, because the terms of billing do not change from month to month on individual plans. Analysis of billing differences is simple, because no adjustments, such as freezes or deferments are involved. Moreover, small number of payment plans to be handled further simplifies forecasting and billing history analysis.

Businesses relying on sales force

Another type of recurring billing business type is represented by companies (using term or open payment plans) that have physical dealerships and use sales force, i.e. a group of sales agents to sell their services, and, therefore, need to pay commissions to sales personnel, and analyze performance of their sales agents. Consequently, revenue forecasting and billing difference analysis are often most relevant in companies where salespeople are involved.

Particularly analysis of billing difference can yield unexpected results when salespeople report sales of a certain number of agreements, while the revenue actually drops. In such a situation one needs to be able to get insight into why this happened. The paradox might be explained by the fact that all the newly sold agreements start their billing in the future, while some of already existing payment plans were frozen or got cancelled.

Another particular feature of this category of companies is that they sometimes need to implement freezes, cancellations and other payment plan adjustments. As a result, these companies need slightly more complex logic to implement the required functionality, in comparison to purely online businesses.

Businesses utilizing collections

The next category of recurring billing companies sell mostly committed agreements and, beside potential payment plan adjustments, also need to implement collections-related functionality in their recurring billing systems.

For these companies collections logic and decline recycling mechanism implementation are particularly important, as their business depends on the ability to successfully collect past dues and retry declined transactions.

Recurring billing system organization models

From the standpoint of software architecture there are 3 common ways in which recurring billing systems can be organized.

Payment-based model

The most obvious way in which a recurring billing system can be organized uses only the notion of a payment plan. The payment plan encapsulates all the terms of the recurring payment.

All recurring billing terms are represented within a single entity traditionally referred to as payment plan (payment schedule). Generally speaking, payment-based model records only what a customer pays, but not what he or she owes.

The key advantage of the “payment plan-based” approach is its simplicity in terms of implementation and usage. The approach is most relevant when billing terms generally remain unchanged (i.e. when an open (unlimited) payment plan is implemented). In this case no complex logic around freezing or cancellation of payment plan is needed (or possible).

This model is most suitable for online subscription-based companies, as it allows to easily implement creation and cancellation of agreements. While elaborate revenue forecasting and billing difference analysis are, generally, impossible with such a system, these features usually not relevant for the abovementioned types of merchants.

Invoice-based model

The notion of a payment plan might still be present in the invoice-based system. However, all of the future payments are recorded through the use of the so-called invoices. In general, an invoice is a record that indicates a charge that either has already been paid (for some product or service), or should be paid by a customer in the future.

In contrast to payment-based model, the invoice-based model allows the company to track outstanding balance of the customer and makes it much easier to deal with situations when multiple payment plans for the same customer are active at the same time. Any past dues a customer owes are accumulated (accrued) in the form of invoices and then balanced by payments.

In an invoice-based system, any customer’s debts as well as any future billing dates and amounts are recorded by invoices.

The advantage of invoice-based approach over the payment-based one is its additional flexibility. Particularly, it is easier to implement freezes, cancellations, pre-payments, changes in invoice amounts and dates, and other adjustments.

The disadvantage of this approach is that is becomes difficult to clearly distinguish, which invoices on the account are already due and were paid, and which are still due in the future. It becomes even more significant when several payment plans are associated with the same customer (as the mechanism becomes even more complex when multiple payment plans are involved).

Invoice-based systems are suitable for those businesses, which are going to use the system for recurring billing only, and utilize a separate system to process one-time purchases. The disadvantage, still, is that the approach might complicate pre-payments or declined transaction recycling process, because the systems using it do not have the functionality for processing one-time payments.

Charge-based model

In a charge-based system both fundamental notions (payment plan and invoice) are present. However, invoices are used exclusively to track purchases already made. To represent scheduled (future) payments, a notion of charge is introduced. A charge (just like and invoice) is associated with the respective payment plans, and records the amount and the date of the charge. The payment information itself and general billing terms are recorded within the associated payment plan.

The concept of a ‘charge’ is similar to invoice concept. For each billing date a charge is created. A charge is processed (a charge converts into an invoice) on a billing date. Under charge-based approach invoices are used to define the already actualized due payments, while charges denote the payments which are due in future.

The charge-based model maintains all advantages of the invoice-based model, providing an opportunity to implement a broad spectrum of payment plan adjustments. Using charges it is easy to implement payment plan freezes and forecast revenues, because for each specific date a specific (easily retrievable) object exists in the data base. Unlike invoice based-model, there is no risk that invoices and charges will get “intermingled”, so it is easy to track how much a customer owes at the moment and how much he or she will have to pay in future.

As we can see, the main advantage of charge concept is that is clearly shows on what date what amount will be charged. In this way one has better visibility into the recurring billing aspect of his business. In charge-based systems it is also easier to analyze billing differences and forecast revenues, taking adjustments (freezes, cancellations, partial cancellations and future cancellations) into account. Consequently, even if a given customer uses several payment plans, it is rather easy to arrange them properly, because all the invoices and payment plans are clearly separated.


Depending on the complexity of a given business, its organization and needs, it should choose the most suitable recurring billing system. If the business model is a subscription-based one with limited number of payment plans, almost any billing system would work. If a business needs to handle many different payments and pricing options, as well as combine one-time purchases and recurring billing (while customers with multiple payment plans are a standard practice) the business should go for a ‘charge-based’ billing system.

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