EMV payment terminal cloud demystified

In our previous articles we mentioned embedded payment terminal solutions, however the concept of payment terminal cloud is still an innovative one. The purpose of this article is to describe a new conceptual approach for embedded solutions, a technology called NIO (non-blocking input/output or non-blocking i/o). The technology allows to create a kind of a payment terminal cloud, that can be manipulated.

The majority of traditional non-embedded solutions, and many embedded solutions as well, are based on the assumption that the POS communicates directly with the terminal (i.e. sends all the messages directly to the terminal).

As we explained in the respective article this communication can be organized through a serial/USB port, or through the local IP of the terminal (using Ethernet cable). However, with the emergence and development of NIO technology, it became possible to use an alternative approach, where the POS does not actually have to ever communicate directly to the terminal.

The concept is very similar to many chat programs. When two people want to chat with each other, their chat client software (remote clients) subscribes to the centralized chat server. When the first person types a message, it is sent to the server and delivered to the chat client of the second person, subscribed to receive messages. The response is delivered back to the first person in the same way.

A similar mechanism can be used to control the work of a terminal. Particularly, a terminal, when initialized, can open a channel for communication with the server and keep it open (persistent connection), so that it can receive any notifications, which are addressed to it. On the other hand, a POS system can also get connected to the server and send commands to the terminal, which is already connected to this server. When multiple terminals get connected to the server in the way described above, a so-called “terminal cloud” is formed. Many terminals are maintaining connection with the server. Once the POS gets connected to the cloud, it can send messages to any connected terminal through the channel, maintained by this terminal.

Formerly, the solution was hard to implement, especially for large number of terminals, as support of multiple persistent TCP connections required too many resources. Presently, NIO technology, which can be built into a terminal and initialized on a server, allows this server to support thousands of open connections without requiring significant resources from the server.

The advantage of the approach is that it allows for usage of the same integration concept for card present and card-not-present transactions. In both cases a POS system sends messages to the server (or payment gateway) in the same way, while in traditional systems card-present and card-not-present transactions represent two different data flows (card-present transactions are, traditionally, handled through integration with the terminal, while card-not-present ones are sent to the gateway).

Another advantage concerns simplification in terms of PCI compliance. The terminal communicates with the gateway, and thus, POS remains completely out of scope, because it neither touches card data, nor communicates directly with the terminal.


If you are a provider of a web-application, or a mobile application, which needs to manage terminals without any local footprint (.dll libraries), or if you use OS, for which there are no available terminal adapters of terminal integration libraries, you need to search for a terminal solution, which is based on payment terminal cloud approach.
If you are a developer of payment terminal solutions, you can utilize payment terminal cloud concept. It makes your solution more promising, as it becomes acceptable for a broader spectrum of potential customers.

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

Contactless Payments Demystified

There is a certain confusion regarding such concepts as EMV contactless payments and magnetic stripe contactless payments (sometimes called proximity payments). Both these concepts denote contactless payments (also called near-field contact or NFC payments), allowing to process card data once the card is placed within the magnetic field of the terminal. Similar NFC technologies are used in both cases.

General info on contactless payments

Contactless technology originally started emerging in the United States with MasterCard PayPass, Visa payWave. Initially, contactless payment technology was an extension of ordinary card-swipe technology. When a card touches the payment terminal, slightly altered track data is communicated to the terminal.

Contactless magnetic stripe payments have approximately the same security level as ordinary card swipes. The only difference is the construction of the card itself, which has to include the necessary components for NFC.

Examples of magnetic stripe contactless payment systems include Google Wallet and Apple Pay. In these systems card data (replaced by a token due to security and PCI compliance considerations) is injected into a mobile device. At some point during processing, the token, which is read off the phone, is detokenized through Apple/Google servers and converted into the actual account number for subsequent processing.

EMV (in contrast to magnetic stripe) contactless payment is an EMV transaction, during which a group of EMV tags is communicated to the terminal (similarly to the case of EMV contact transactions).

Limitations of EMV contactless payments

Due to the nature of contactless payments, there are certain limitations, which distinguish contactless payments from contact payments. These limitations are related to security and technology related issues. Let us take a closer look at the specified limitations.

Amount limitation

EMV contactless cards and payments are often used in scenarios, which require swift completion of the transaction. Consequently, contactless payments are often conducted without verification of either signatures or PINs (although both options are possible in contactless transactions). That is why, when application parameters for EMV are configured, a maximum amount of a contactless transaction is established (according to the needs of the business).

No issuer script processing

In some instances issuer may want to send some information back to the chip on the card (a common feature in the contact EMV). While EMV contactless standard does make provision for the second “tap” (or touch), it is often assumed that there is going to be just one tap. Consequently, in most cases, it will be impossible to send the issuer script back to the card as part of contactless transaction.

Automated application selection

We should remind that an ordinary magnetic stripe contains only the information about the card, its expiration date, and the cardholder’s name, which can be read by the terminal and used at some further stage of the process. In contrast to a magnetic stripe, an EMV chip contains special applications. Through these applications the card interacts with the payment terminal (in contrast to magnetic stripe card). In some cases there might be several specialized applications, recorded on a chip (for instance, applications for debit networks, for Visa processing in the US, or for processing of Visa International). Depending on transaction type and merchant type, the terminal chooses the most suitable application, the application is activated and used for information exchange between the terminal and the card. In some cases there can be several applications suitable for specific situations. In case of contact EMV the selection can be made by the cardholder. However, in contactless situation the selection very often happens automatically by default.

Some applications can be intended for card payments at petrol stations, while others can be intended for card usage in specific countries of the world. Common debit application IDs (AIDs) are intended for working through PIN-less debit networks. MasterCard brand AIDs are intended for international payment processing (for cases when a debit network cannot be accessed).

In case of contact payment the cardholder can select an application, which is most suitable for him. In case of a contactless card payment the cardholder might not have such an opportunity. As application selection is performed automatically, it becomes of great importance for merchant to properly configure automated selection process to choose the application, which is most suitable for a particular business context in terms of eventual processing cost.


Contactless technology provides convenient means of payment, allowing cardholders and merchants to save time. However, this technology often complicates the process of certification. As a result, before you decide, whether you want to accept contactless payment cards or not, you have to verify whether the limitations of the technology will have any negative consequences for your business, and whether it will be problematic to invest time and efforts, needed for implementation of contactless technology in addition to contact payment processing. Also remember, that for some businesses (and, possibly, for your business as well) it might be appropriate to completely switch to contactless payments and give up contact EMV payments, and there are numerous models of terminals that can only accept contactless payments, and they are cheaper than terminals which can do both; if you switch to contactless payments only, certification process will, again, become simpler for you.