Implementing Your Own Payment Terminal Solution

If you are a player in the retail space, thinking that your business needs support for payment terminals, or if you are considering different payment terminal solutions in search of the most suitable one, this article is for you.

The need for customized payment terminal solutions is gaining urgency in view of approaching introduction of EMV standards and requirements in the US, scheduled for the end of 2015.

In this article we are going to consider several solutions, available for payment gateways and payment service providers with respect to their EMV strategy.

In essence, a terminal is a mini-computer with its own OS, where a terminal application has to function. Payment gateway must integrate with this terminal application to support EMV properly.

Payment solution offered by the acquirer

The first and, seemingly, the simplest solution is using payment terminal application, offered by an acquirer.

Many present-day acquirers offer you some form of payment terminal solution, which some PSPs or gateways may consider using. Upon closer inspection, however, you realize that there are a couple of issues with that.

One of the issues is that most payment terminal solutions (applications) offered by acquirers are tied directly to their platforms. Particularly, because of the tight EMV regulations, they avoid sending transactions from the terminal to some third-party gateway, intermediary CRM, or software system, which would then forward them to the acquirer. This may present a problem, because they need to keep track of these transactions to accommodate the business model of a PSP/gateway. The problem with the solution is that these transactions become invisible to the third-party gateway providers within their systems.

Because of that, many gateways and PSPs choose to integrate their software system with a terminal in a way which they can fully control.

Integration with a terminal

Integrating with a terminal can be done at two levels. At a higher level a PSP/gateway can utilize an existing terminal application and integrate with it using integration SDKs. At a lower level a proprietary embedded application can be written and subsequently integrated into the overall payment processing ecosystem.

SDK-based integration

The advantage of the first solution is that the SDK-based integration, usually, is much quicker than development of an embedded terminal application. Major payment terminal manufacturers (such as Ingenico, VeriFone, and PAX) offer their own terminal applications, which can be used in various ways, and thus, it is possible for payment gateways to take advantage of these applications.

While this solution is the simpler of the two, it has its disadvantages:

  • The gateway will not always be able to customize the terminal application (its interface or logic). For instance, you might be unable to add non-payment-related functionality, such as quality survey, to the application, when you need it.
  • SDK-based integration method may not be conceptually suitable for your application. Traditionally, platforms that used terminals, were desktop applications (only desktop applications existed). That is why many terminal integration SDKs still rely on the so-called native code, such as Windows-compiled DLL library. This imposes the requirement on the application to be able to deal with the native code. While this is, generally, not a problem for a desktop application, it does present a challenge for a web-application, which operates from within a sandbox, and, usually, does not have security privileges to operate at such a low level.

Embedded solution

The advantage of an embedded solution is that you can customize everything, and the application can do whatever you choose for it to do. You can develop an SDK or integration API, that will work for you, or your customers in any way, that you find appropriate.

On the other hand, this solution has a price tag attached to it, and is associated with some challenges:

  • Writing your own terminal application requires your own specialized knowledge, and a special costly certification, that has to be competed with the respective vendor in order to acquire preliminary knowledge and access to SDKs, allowing to do embedded development.
  • Building and testing the application, definitely, takes time. Therefore, immediate integration with the payment gateway solution is impossible.

In the next post we will describe some specific methods of integration and implementation of various SDK, allowing you to incorporate the terminal application into some software solution or payment ecosystem.

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, 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.