On the Way to Collaborative Payment Processing

Many businesses go through an evolutionary cycle as they grow. They usually start as small companies with very basic needs. Then at some point, as their processing needs become more sophisticated, they tend to outgrow the payment processing platform, chosen at the very beginning. In this article we are going to follow through a typical evolutionary path of such a company, see, which challenges it experiences, which traditional solutions can be used, and what new collaborative payment processing technology can offer.

Our story starts in a small warehouse. A group of people decides to open a book-selling business and launch a web-site, through which they are going to sell books.

Classical third-party payment gateway service

Having neither previous transaction processing volume nor PCI infrastructure, the company chooses the simplest route: to partner with an existing payment gateway, that can connect it to one or more processors that it needs.

As time goes by, the book-selling business expands rapidly, its revenue grows. It gets recurring orders from schools and universities. It starts opening stands and kiosks at book fairs, in airports and other places. Consequently, the need for card-present EMV solution as well as recurring billing solution arises. New payment processing logic is required. Beside that, the company is expanding to other geographies. Support for more currencies is needed.

The current gateway cannot accommodate all of these needs. The company starts thinking of integrations with several gateways. However, these gateways solve similar problems in different ways and cater to different market segments. The gateway, used for US dollars, has robust recurring billing, while the gateway used for Euros has an excellent on-boarding system. And still, there is no common denominator and the bookselling business has to compensate all the differences using its own development team, and, beside that, implement integrations with multiple payment processing back ends.

Gradually, the bookselling company reaches a decision to invest in its own infrastructure and develop some in-house payment gateway that would be used as a centralized system of record.
The managers start to analyze the problem of in-house payment platform development and list related costs and tasks, such as: logic to be developed, integrations, needed for payment processing, implementation of recurring billing functions and reconciliation processes. At the same time, they realize the additional costs of a new data center, PCI audit procedures, tokenization appliances and other operation costs. The company understands that the problem is too complicated to try to solve it with internal resources only.

As a result, the management decides, that the payment ecosystem should be based on some existing open-source payment technology.

Open-source payment gateway solution

The bookselling company licenses and implements an open-source payment technology (adding the missing functionality in-house) and its growth continues. Now it has its own infrastructure, which it fully controls.

With time, however, the company starts facing new problems. First, it has to redo all the necessary certifications and implement new integrations. These integrations start taking too much time to complete. Second, supporting card-present solutions in different geographical locations is not an easy task, so it poses additional challenges. Third, as the company’s core product begins to mature, the management decides to expand their operations to Europe (in addition to North America, where the business is already solidified), and understands that they need to include marketplace offering, allowing participating stores to use the company’s merchant services.

It seems like an endless cycle of growing needs, product updates and constant re-certifications. The solution comes in the form of collaborative payment processing.

The essence of collaborative payment processing

While a payment gateway can connect to a bank or a processor, it can also connect to another instance of itself, running elsewhere (in another ecosystem). Therefore, two payment ecosystems, that use the same payment processing platform as foundation, can connect to each other, forming a cloud.

While the bookselling company expands to Europe, it finds out that there is a payment service provider that uses the same open source payment processing technology. This technology has a cloud capability, allowing the two instances to get connected and, automatically, provision accounts and set them up for processing, as well as process transactions through each other.

The company signs a contract with its European partner (PSP), which allows it to underwrite merchants using the integrations of the PSP. At the same time, collection of merchant and transaction data (as well as other data) is performed using the existing in-house technology, built by the original business. As a result, without the need for any additional integrations, the bookselling company immediately gains access to all of the processing capabilities of their partner in Europe.

After some time, as the company expands further, a similar collaborative payment processing mechanism is replicated in Australia. The three companies (headquartered in the US, Europe, and Australia) form a three-sided partnership, allowing them to benefit from each other’s processing functionality.


Each individual case of a company’s growth is unique, and you should be looking for solutions that work best for you. However, the example, described above, is very typical of what we have observed within the industry. If you feel that this scenario resembles your business and would like to learn more about the concept of collaborative payment processing, we will be glad to provide additional information at UniPay Gateway.

If you are interested in the diagram illustrating this topic, visit UniPayGateway website.

In the next article we are going to describe the concept of payment gateway cloud in greater detail.

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 Authorize.net 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.

Getting out of PCI scope


More and more companies nowadays accept credit card payments. Payment card industry is regulated by Payment Card Industry Security Standards Council, which has specific security requirements. According to these requirements, each company, dealing with card data, has to go through regular PCI audit, which is quite a costly procedure. That is why many companies are trying to find the answer to the question: how can a business accept payment cards, but remain out of PCI scope.


The general problem is to move the existing payment system, which is presently in PCI scope, out of it. At the same time, the system has to be able to perform its functions as before.


While some companies cannot avoid PCI audit, because their payment systems are too large, a number of merchants and software companies are technically able to reorganize their infrastructure in such a way, which would allow them to either get out of PCI scope completely, or reduce their “exposure level” and PCI audit costs.

From conceptual viewpoint the problem has several complexity levels.

  • Level 1: Card present vs card not present. If only CNP transactions are involved, it is much easier to reduce exposure level.
  • Level 2: Number of front-end systems.
    If only one front-end system (for instance, a POS system) is involved, the process becomes much more transparent. If there are many front-end systems, a solution must be found for each of them.
  • Level 3: Which kinds of applications are involved?In some cases web applications might be easier to remove out of PCI scope, than desktop applications. If you are dealing with a legacy system which uses obsolete technologies and has limited functionality (or, maybe, the developers who created the system are no longer with the company), the task becomes even more complex.
  • Level 4: Are recurring payments involved? If the answer is “yes”, then there is a need to store cardholder data, and the matter of exposure reduction gets trickier.
  • Level 5: Are all the merchants using different payment systems? Say, if you are a software company, the users of your software can either partner with the same PSPs, or have different independent (individual) processing solutions. So, is payment processing
    unified for all users of your platform, or do they have customized processing solutions associated with local banks or processors?


In order to optimize your business infrastructure and successfully get your company out of PCI scope, or at least, reduce your exposure level, you need to perform the following important steps.

  • Consult the PCI auditor. Whatever strategy you have in mind, discuss it with the PCI auditor before implementation. Then compile all the necessary documents to start the process.
  • Decide, which of the components of your payment ecosystem have to be phased out. In the simplest case the system consists of a single software package. However, in many cases, it can include several packages, different terminal solutions, etc, and these components and solutions have to be prioritized.
  • Decide, if (similarly to the previous step) you need to sunset your integrations with some processors and migrate merchants to other processing platforms in order to unify and simplify the process.
  • Decide, whether you need to unify payment processing across your customers. Do you, potentially, need to reduce the number of supported processors and simplify the overall infrastructure, in order to make it more transparent.
  • Decide, whether you need to store cardholder data. If your company uses terminal capture, then you have to send the file with card numbers to your processor on a regular basis. Consequently, you have to store card numbers within your system. However, if you switch to host capture, card numbers no longer have to be stored in the system and sent to the processor.
  • Analyze the following two basic issues in the context of exposure level reduction: card flow and card storage (if necessary). Card flow can be handled in two ways: either using payment pages (mostly for CNP solutions), or (for card present solutions) using P2PE on card readers or payment terminals. For card storage a classical solution is tokenization of card data.
  • Verify, whether CNP, card present, and recurring billing solutions are supported by each of the PSPs your system works with. We should remind that if recurring billing is involved, you or your partner PSPs have to store and, consequently, tokenize card numbers. If some of the PSPs do not support all the necessary services (or if it is more relevant to work with some unified processor-agnostic service and eliminate the necessity to support different tokens), then you should consider partnering with some independent (processor-agnostic) tokenization services. Some information on migration from one processor to another can be found here.
  • Plan the integration works which have to be done for implementation of the new infrastructure. These may include integrations with tokenization services, P2PE service providers, and other entities.
  • Plan cardholder data migration process. If actual card numbers are stored within your system, or if your current tokenization solution is only partial, you need to decide, how and when card numbers will be migrated.


Even if you understand that you are unable to get your system out of PCI scope completely and all you need is to simplify the process of cardholder data handling, you might consider using some standardized open-source payment technology (such as UniPay Gateway), which is capable of performing all the necessary functions, within the existing payment ecosystem. This step will allow you to unify many internal processes and, thus, simplify PCI audit procedure.

Terminal Solution Components

This year support of EMV standard becomes a mandatory component of payment systems of US-based businesses. Consequently, more and more merchants ask themselves how they are going to implement their terminal solutions in view of the need EMV support.

The purpose of this article is to describe the components of a modern terminal solution in order to help those who are trying to define their strategy of payment terminal usage. The subject is especially relevant for large-size merchants and payment facilitators, who have to deal with a large number of terminal deployments.

A modern terminal solution has to incorporate three key modules, which will address three aspects:

  • Fulfillment management – for ordering, injection, and operation of terminals
  • Terminal application – for transaction processing
  • Terminal support and management system (TMS) – for configuration and updates of terminal applications

Let us address each of these aspects in detail.

Payment Terminal Fulfillment

During fulfillment process the merchant orders a certain number of terminals of specific models with specific injection keys, while the respective fulfillment center (which works directly with the manufacturer) handles the order and supplies the terminals to specific locations (points of sale).

In many cases large payment facilitators and gateways have to work with more than one terminal fulfillment center. The reasons are as follows. First, a fulfillment center may be out of stock for a particular terminal model, so you have to order this model from some other supplier. Second, not every fulfillment center can inject every processor’s key (usually, fulfillment centers have agreements with limited numbers of processors). This is particularly difficult when processing crosses borders, because fulfillment centers tend to specialize within a specific country of operation. Consequently, companies, dealing with merchants in different countries, or doing international processing, may require special tools to manage the entire process and ensure that proper terminals with appropriate keys are ordered from appropriate suppliers.

Another important fulfillment-related issue is injection of third-party keys. It should be noted that lately implementation of end-to-end encryption solutions has become a common practice. In these solutions, PAN data is encrypted with a key. Most payment facilitators and payment gateways prefer to use their own encryption keys. However, not all providers of fulfillment services are equipped to handle the third-party key injection. In order to have the right to inject third-party keys, a company needs to be equipped with special procedures and have special certifications. Beside that, a special agreement is needed by a company to be authorized to inject encryption keys on behalf of a specific third party.

When you consider your terminal solution, all these issues need to be taken into account (even if not all of them are will be handled by your in-house system).

Terminal application

There are several terminal manufacturers and numerous terminal models. Similarly, there are many different terminal solutions. However, from a global perspective, all terminal solutions can be divided into two categories.

  • Terminal applications which have local footprint
  • Terminal applications with no local footprint

A terminal application “with a local footprint” requires installation of some special components on a workstation it is connected to. Usually, these components are DLL libraries, which represent one of the most common approaches nowadays.

A terminal application “with no local footprint” does not require installation of any native libraries or drivers on a workstation that is going to manage the terminal.

The second solution is, naturally, the preferable one, as it allows you to access the terminal and work with it in a unified manner from different web or desktop applications, under different operating systems, using different mobile devices (such as smart-phones and tablets\pads).

Terminal management system

Once the terminals are deployed, they need to be supported and maintained. In this regard several issues need to be addressed.

First, a terminal may break. Some plan of action must be developed for a case when something goes wrong with a terminal (i.e. how the malfunctioning terminal is going to be replaced).

Second, from time to time the terminal logic might need to be updated. Both embedded terminal content and DLL applications have to be updated from time to time.

Finally, the advertisement content of the terminal needs to be updated as well.

A terminal management system must be capable of supporting all the listed functions and updates.


We’ve presented a brief overview of a terminal solution at the high level. In our subsequent installments we are going to address specific terminal solution components and aspects in greater detail. We encourage you to study the topic carefully before making decisions about your preferred terminal solution strategies. In our future articles we will cover more related topics.

Integrating Terminal Application into a Payment Ecosystem

If you are implementing your own terminal application or planning to integrate terminal applications into your payments ecosystem, you have to choose potential ways of interaction with payment terminals.

In our previous article we discussed the pros and cons of several payment terminal solution implementation options. Now we are going to analyze several approaches to integration of payment terminal applications into your payment ecosystem.

In essence, you can choose from among the two conceptually different approaches: standalone terminal use and integrated terminal use. The first approach allows the terminal to function on its own. The second approach envisions control of the terminal by point-of-sale (POS) application.

Standalone terminal use

You can often witness a classical example of standalone terminal use in many convenience stores. In such a store, after all the items you’ve picked are rung up at the POS, the cashier keys in the amount into the terminal and hands it over to you to complete the payment. In this case, the POS application has no interaction with the terminal.

When the terminal functions independently, in order to process a payment, you only have to input the payment amount. After that, the payment is made, while POS application, through which the sale was made, is not even “aware” of that.

As more and more commercial and open-source POS systems become available for various segments of businesses, the demand for standalone terminal offerings is gradually declining, because more and more businesses desire to have an integrated approach.

Integrated solution for terminal application

To integrate a POS system with a terminal, you have to connect the terminal to the workstation (on which the POS system is installed). Traditionally, POS was connected to the terminal through a serial port (presently – through a USB port). There are several ways of structuring interaction between POS and the terminal.

Fully integrated versus semi-integrated approaches

When it comes to integrated terminal solutions, there are two terms, that are commonly used to define the communication paradigm between POS and a terminal: semi-integrated and fully integrated.

Traditionally, all of the applications were fully integrated. In a fully integrated approach a terminal is used as a reader, obtaining card information, which is then consumed by the POS system, formatted into appropriate message, and sent to the gateway for processing. In a semi-integrated approach, the terminal is used as a standalone processing unit, which collects payment information, formats the appropriate message, and sends it to the gateway or processor for authorization.

Regardless of the communication approach used, there are several ways, in which the actual integration can be done.

Integration through an SDK

Traditionally, the terminal was managed through low-level libraries, allowing communication with serial/USB ports. In case of Windows these were the DLL libraries, provided by the manufacturer of the terminal (as we’ve mentioned in the previous article).

The advantage of the approach is that it is the most popular and widely spread one, as respective SDKs are available, and generic drivers such as uPOS, JavaPOS, etc, are available and supported by the existing POS systems.

Some payment solution providers see the advantage in the fact that most of the terminal behavior-controlling logic is located outside of the terminal, i.e. on the POS end, and, thus, in order to change the application’s “behavior”, no updates within the terminal are required. Consequently, you can reduce dependence on terminal management system (which is primarily used for remote terminal application updates).

The disadvantage of the approach is that it is not always suitable for web applications, which are not allowed to access to the low-level services of an operating system. While such applications can fall back on usage of ActiveX controls or Java Applets, these approaches present various security and deployment challenges.

Integration through a REST API

An alternative approach is to connect to the terminal through a REST API.

The advantage of the approach is that you do not have to deal with native code. Any application, capable of making web-service calls, can communicate with the terminal and control it.

The disadvantage of the approach is that all the logic driving the terminal’s behavior is, usually, deployed within the terminal as the terminal application. In this case, any enhancements of the application require updates within the terminal. Consequently, it is difficult to maintain such a configuration without involving a terminal management system of some sort.

Non-integrated approach

In some cases, the POS system does not need to control the terminal’s behavior at every step of the process. In such cases, POS developers prefer not to do integration with the terminal of any kind. However, you might still need the terminal to receive the information on the amount to be collected, while your POS system has to get the information about payments going through terminal.

In such cases you can utilize the so-called non-integrated approach.

When the POS system needs to process a transaction, it sends it to the gateway (without payment information included). Once a key on a terminal is pressed, the terminal connects to the gateway and checks if there are any pending transactions to be processed. It “sees” the transaction, that the POS sent previously, collects the payment information from the cardholder, and sends it to the gateway for processing. Once the gateway authorizes the transaction, it issues a call to the POS system, informing it that the original sale request has been fulfilled and the payment has been successfully made.

Naturally, the solution is available only for systems with a centralized processing server, such as web-based systems.

The advantage of this approach is that web-based systems can use the terminal without actually integrating with it.


Now that you have better understanding of payment terminal integration issues, you can decide, what terminal strategy is best for your business.

Payment Gateways and High Availability Concept

The purpose of this article is to familiarize payment gateway software users with the benefits of high availability and fault tolerance concepts. These two concepts are vitally important for various merchant services industry players, because transaction processing (especially, real-time processing) became mission critical for most businesses, such as online stores, online ticket booking and purchase systems, hotel booking sites etc.

More and more transnational online businesses emerge, which are targeted at customers around the world. Payment system of such businesses must be available 24/7 with the minimal number of the maintenance windows. Fault tolerance in itself is another reason for utilizing cluster architecture for transaction processing. If some node of the system fails, the customers must not even notice it.

Why are high availability and fault tolerance important?

There are several reasons why you should think in advance of the concepts of high availability and fault tolerance as you design the architecture of your future payment ecosystem:

  • Downtime reduction. You should minimize downtime, because your clients might be located around the world, in different time zones. On the other hand, your payment software still needs to be updated from time to time (and this, generally, requires some server restarts or downtime). If your system is designed with high availability in mind, then you are able to service all your customers 24/7, and still perform maintenance operations and updates when necessary.
  • Physical hardware failures. You might experience physical hardware failures, including database storage failures. For these situations, you must develop an effective backup strategy. Sometimes, however, doing a lengthy recovery process from backup and is simply not an option, because the system will not be functional while the process executes. For such cases, maintaining a cluster of data bases, both of which are active at any time, is the only way.
  • Division of labor. You might (sometimes or regularly) have a consistent high volume of authorizations going, while somebody drops a large file for processing, or some resource-intense settlement process has to execute. Running all of these processes on the same server can significantly impair the ability to do real-time authorizations. Therefore, it might be necessary to segment the functionality, so that certain nodes of the cluster are dedicated to authorization, some handle settlement and batch file processing, while other nodes can handle reports and data export.
  • Resource utilization optimization. Similarly to functionality-based segmentation, sometimes a need for customer-based segmentation might arise. Customers with some specific behavior patterns, or customers from specific time zones, can be directed to respective nodes, “reserved” for them (always or at a certain time of the day).
    Some of the company’s customers process transactions 24/7, while other customers process large volumes at particular time of the day or month (these are merchants doing recurring billing through real-time transactions). In such case one node should be dedicated to merchants who process transactions 24 hours a day and have evenly distributed processing patterns, while dedicated nodes could be used for merchants who only process at certain times. Based on the processing times, they could be arranged in such sequence that the servers are never overloaded with transaction volume.
  • Conclusion

    If you are serious about payment processing and customer service, you have to be serious about high availability.

3 Companies, that Need Open Source Payment Gateways

The purpose of this article is to familiarize various merchant services industry players with the benefits of an open source payment gateway.

During the last several years more and more open source software products emerged.
One of the reasons of rapidly growing popularity of open source software products is their collective development, where each company using the software benefits from any development that any other party introduces. Consequently, the concept of open source software development became particularly prevalent among the companies that developed programming tools and libraries; however, it was also adopted by business software providers, such as shopping cart and POS software vendors etc.

Payment gateways, on the other hand, traditionally, were commercial closed-source products. Source code represented strategic value for payment gateway operators. Payment gateway software was, originally, developed by the company, which operated the payment gateway. Payment gateway operators did not sell the software code to other parties and left all the implementation know-how to themselves as a trade secret. Now, however, we are witnessing the emergence of companies, which offer payment gateways as licensable platforms (technological commodities); they do not host them themselves, but rather license them for others to host and use. As a result, the open source concept became especially popular in such cases, because usage of open source in technical products of such kind is a convenient and practical option.

Who might need open source payment gateways?

Many people think that payment gateway software is needed only by companies that accept credit card payments. In reality, companies that facilitate payment processing or process transactions on behalf of others would also greatly benefit from open source payment gateways.

Here are the three types of companies that might benefit the most from payment ecosystems, built on top of open source technologies:

  • Payment facilitators (or payment service providers), i.e. entities, that process large transaction volumes, but do that through some third-party processor (acquirer))
  • Mainframe platform users, i.e. legacy system users
  • Software and service companies, integrated with multiple payment systems and gateways (such as Authorize.net, PayPal, Stripe, Square, etc.) (check the article on various types of payment processing solutions here)

Let us now look at each of these three groups of companies in greater detail.

Open source payment gateways for PSPs

Payment service providers, traditionally, relied on several payment gateways, because the combination of these gateways could offer a broad scope of functionality, and wider access to acquirers. As a consequence of that, they had to define their operational procedures around multiple unrelated payment systems.

Open source payment gateway architecture could function as a universal, unifying and flexible solution in such cases. On one hand, the open source payment platform could be used as an intermediary system that all additional gateways would be integrated with. In this case, it would function as a single point of record and, potentially, single point of integration for customers of a PSP. On the other hand, such an open source platform with the ability to implement direct connections into acquirers could serve as a replacement for other legacy gateways the PSP uses.


A payment facilitator partners with FirstData and Vantiv to process transactions in the US and Canada, and with another couple of gateways to support Australian and European processing. Due to the nature of its business, it has to deal with four different gateways. The payment facilitator could integrate these four gateways into a single open source gateway, which he could then adopt as a single system of record and which all of its customers would integrate with. Consequently, as more connections are needed, they could be added at the back end, without affecting the existing front-end integrations.

Open source payment gateways for legacy system users

Legacy systems are mainframe-based software packages. Initially they were written 30 to 40 years ago using languages such as Fortran, Cobol or RPG. They are still widely used in financial and banking sectors and many of the billing companies rely on those.

A legacy system was usually developed to satisfy the needs of a particular company, which used it. Today, such a company might need to replace the outdated (but still working) system with a new one, because it becomes too complicated to maintain the existing legacy system. However, it is really problematic to find an alternative system, so perfectly fitting into the business model of the company. And it is equally difficult for the company to develop a replacement system using its internal team from scratch.

In this situation, an open source payment gateway is a viable solution, because, it already has all of the foundational logic implemented (so no significant upfront development is required). At the same time, its open nature allows the company, that uses it, to introduce any changes that it needs to make it fit better into its business model.


A billing company using mainframe could choose to build its new payment ecosystem using an existing open source payment platform. Normally, the migration process can be broken up into phases. The initial rollout could rely on the existing functionality with minor modifications. Within each phase various changes in logic could be introduced, gradually adjusting the entire system to the needs of the company.

Open source payment gateways for software companies

There are many software companies today, that have implemented support for various payment gateways within their products. Examples of such products include event reservation systems, shopping carts, POS systems, restaurant software etc. These companies, traditionally, wanted to distance themselves from payment processing and concentrate exclusively on domain-specific functionality. At the same time, they wanted to support the widest number of payment gateways and processors available.

As the number of supported gateways increased, it became more and more difficult to maintain all the connections by the internal development team. Relying on third parties for development of the necessary plug-ins is not always the best option. Since such integrations are, generally, tightly coupled with the main application code, changes to the application can cause malfunctioning of pre-written integrations, especially, those delivered by third parties.

Consequently, such companies could benefit from an open source payment platform by delegating all of the payment processing logic and management of the payment connections to the external payment system, and by maintaining a single unified integration with that system from the core product.

This way any changes in the core product will, probably, have minimal effect upon the existing integrations, and all new integrations can be developed in a unified fashion, taking advantage of the open source nature of the payment platform.


A classical example is a shopping cart vendor, trying to support as many payment gateways as possible, in order to reach the broadest spectrum of potential clients. Still, some clients have integrations with some payment systems, which are not currently supported. Usage of open source technology as the foundation of the payment ecosystem gives such a vendor an opportunity to implement the logic for the integration that it needs without any changes in the core product. This alleviates pressure from the shopping cart vendor when it comes to implementation of new integrations.


If your company in the course of running its business has to deal with multiple payment gateways or payment processors with a need for a unified entry point, you would, likely, benefit from an open source payment gateway technology, and we encourage you to research that topic more.

EMV Certification in a Nutshell

The purpose of this article is to familiarize integrators with EMV processing, help merchants understand the process of EMV certification and estimate its cost.

The relevance of EMV certification

EMV stands for Europay, Mastercard and Visa, and denotes a worldwide transaction authentication standard. The standard is based on usage of integrated circuit cards, which increases the security of EMV card transactions in comparison to magnetic stripe cards. More information on EMV standards can be found here.

From January 1, 2005, merchants in EU area are held liable for all fraud resulting from transactions processed in the systems, which do not support EMV. In the US, EMV certification also became an extremely relevant issue after the associations declared that the liability will be placed on merchants at the end of 2015, i.e. if a person wants to make a purchase from a merchant, using the EMV card, but the merchant doesn’t have an EMV terminal, and the transaction ends up being part of fraudulent activity, it is the merchant who is going to be held financially responsible for the incident’s consequences.

Although many merchants can purchase EMV terminals from the acquirers and do not necessarily need to conduct the in-depth analysis of EMV certification process, gateways, payment facilitators, as well as companies, that maintain their own proprietary payments ecosystems, have to face the question of how to undergo EMV certification, i.e., how to add EMV support into feature sets of their products.

Let us move on and review the EMV certification process in greater detail.

EMV certification phases

Before starting an EMV certification, a company needs to make a decision about the three key components of the process:

  • Terminal(s) (hardware device) that will be used to read EMV cards. Some information on payment terminals can be found in our respective article
  • Payment gateway software or some form of software package that will deliver transactions to the acquirer
  • Acquirer(s), that will process the transactions

After these decisions are made, the company can proceed with the EMV certification, that is, generally, comprised of two sub-certification processes (phases): host integration and EMV certification.

Payment processing host integration

Generally, there are no certification fees involved in this phase, and the main cost is the cost of development of the integration code. It involves integration on the message level between your system and the acquirer. As part of this integration, a proper message format is implemented to enable a payment gateway to submit EMV fields to acquirer’s system in a format that it can “understand”. In a sense, the process is similar to classical integration, described in the respective article.

EMV certification

It is a process, in which an EMV terminal (a terminal, supporting EMV card processing) and a so-called EMV toolkit are used. Special test scripts, certified by the acquirer for every association, have to be executed with the help of the EMV toolkit. The results of execution of the test scripts are submitted to the acquirer to be considered for review. The acquirer forwards the results to the associations for their final approval.
Usually, EMV certification involves an administrative fee (charged by acquirers), ranging between $2,000 and $3,000 for every formal test script run. Re-certification process has to be initiated every time when a new hardware device, using a different EMV kernel is added to the previously certified EMV-processing pad.

For example if any VeriFone mx9 series device has been previously certified, any other device of a kind is automatically covered by that certification. But in order to use some Ingenico device, you would have to initiate another EMV certification (even if you are going to utilize the existing host integration and the same back end).
The most popular EMV toolkits include ICC and B2 toolkits. Particularly, these toolkits are quite popular among acquirers in the US.

Selecting a device

The list of all desired devices to be supported needs to be compiled in advance and included into the initial certification. While selecting the devices, one should understand that only terminals and readers, which have EMV level 1 and level 2 certified kernels, can be used.

An EMV toolkit works as both card reader and card writer: it both reads data from the chip and writes new data on it to be read during subsequent transactions.

Developing terminal application

As we’ve mentioned above, firstly, a business wanting to process EMV transactions, needs to select payment terminal, supporting EMV and certified by the acquirer.
Secondly, the integration needs to understand that most terminal manufacturers will not provide a stock payment processing application with the terminal. In this sense, a terminal is similar to a PC with just an operating system installed, without any applications. It is the integrator’s responsibility to procure (develop or license) a terminal payment application, compatible with the hardware and the operating systems of the models of the terminals that it wants to support.

There are various ways to simplify the development process: it can be outsourced, or some existing applications can be purchased; but, generally, it has to be accounted for in the budget for the project.

For deployment and management of the terminals, software updates, remote configuration management a separate software package is used, which is, generally, called, terminal management software.

This terminal application has to be able to utilize required peripheral devices, such as card readers, signature capture etc., and accommodate whatever types of transactions that are going to be required (credit cards, debit cards, gift cards, EBT, etc.).

Most large terminal manufacturers (such as VeryFone) maintain their own payment gateways. A business can purchase a terminal with the manufacturer’s application on it, which is, generally, “tied” to the manufacturer’s gateway. Therefore, if a business wants to connect such EMV terminal to a different gateway, it, generally, has to undertake some software development.

Selecting acquirers to partner with

A business, planning to integrate with several acquirers, needs to understand that each acquirer requires a separate EMV certification for each country, in which the business is going to process.

An average cost of EMV toolkit (which is used in every EMV certification) ranges from $10,000 to $30,000 per user license. That is why, when the acquirer is selected, it is advised to consider the models of the toolkit that the acquirer supports, so that potential cost savings can be realized by going with specific acquirers and toolkit vendors (by using a single toolkit for two or more certifications across different acquirers). And if you are already in possession of a certain toolkit, it never hurts to ask the acquirer explicitly, whether they would accept the tests using your version of the toolkit.


If you are a business considering the idea of going through EMV certification process, you need to select the devices you are going to use, payment gateway and acquirers you are going to partner with; also you need to decide how to get or develop terminal applications. And, of course, you need to carefully plan respective budgets.