EMV Fallback Transaction

This article continues the series dedicated to EMV standard and EMV payment card processing. In it we are going to describe transaction fallback mechanism, its purpose, and types of EMV fallback transactions.

As we know, the general purpose of EMV technology is to increase the level of security and protection of cardholder data during the transaction. That is why it is always preferable to perform transactions when the card is equipped with a chip which is properly functioning. However, in some cases EMV transaction is impossible, in spite of the fact that the EMV chip is available.

For example, the payment terminal does not support chipped cards at all, or the slot, intended for reading of card chips is temporarily out of order.

Sometimes a chip cannot be read because it is damaged and the terminal cannot read the data from this chip.

For situations like these EMV standard provides the concept of EMV fallback transaction. If the data cannot be read from the chip, one can try to swipe the EMV card like an ordinary magnetic stripe card (swiped EMV fallback transaction). If the swipe doesn’t work either, it is possible to input the card number into the terminal manually (manual EMV fallback transaction).

It should be stressed, that EMV transaction fallback is an independent concept, and EMV card swipe cannot be viewed as an ordinary swipe transaction. This approach allows to prevent EMV terminals from being used for unintended purposes. That is, in theory, a fraudster could use a stolen EMV card with the terminal and try to swipe it or input its number manually (instead of scanning the chip, which might lead to detection of the fraudulent activity). However, EMV terminals are programmed in such a way that EMV card swipe cannot be attempted unless and attempt of reading the chip has already been made (although, technically, manual input of card number can still be attempted before the chip). This is implemented using a special service code, present in the track data. When a swipe is performed, the terminal analyzes that service code, it can block the swipe and display the message, requiring to insert the EMV card. If an attempt to insert an EMV chip has been detected, the terminal allows the operator to subsequently perform EMV fallback transaction. In this case, when the transaction is processed, a special flag is raised, indicating that it is a fallback, and that the initial attempt to read the chip was unsuccessful.

Conclusion

When implementing your EMV application, you need to take fallback mechanism into account. Although there are no strict requirements as to the order of fallbacks, it is recommended to develop protection mechanism, preventing the card from being swiped before the chip has been attempted. If the chip cannot be read, it is recommended to perform the swipe, and after that (if the swipe is unsuccessful) – try manual fallback.

If the payment terminal supports both contactless and contact EMV payments, these payment types should be “interchangeable” (if contact transaction is unsuccessful, conactless payment can be attempted and vice versa). If neither contact nor contacless payment comes through, swipe and manual fallback can be attempted.

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.

Conclusion

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

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.

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.

Conclusion

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.

Offline Processing: Store-and-forward

The purpose of this article is to describe the store-and-forward mechanism implemented in payment gateway software in the cases when transaction processing becomes impossible due to temporary loss of connectivity with the processing “back end” (for instance, a bank) or due to some other errors.

As we explained in one of the previous articles, issues with transaction processing might be caused by one of the two conceptually different reasons: timeouts and errors. While the previous article focused on timeout handling, this one focuses on offline transaction processing, which is made possible by implementation of store-and-forward technique.

The essence of store-and-forward approach

Originally, when modems were introduced and connection was not always stable, the so-called offline transaction processing concept was developed. Usually, offline transaction processing is implemented at the level of a payment terminal (as it is a standalone device, independent from the host application). Sometimes, this solution is referred to as store-and-forward. On the basic conceptual level, the terminal stores transactions and, once connection is reestablished, it sends them to the host application for processing. The transaction is not actually submitted for processing immediately, but rather a “fake approval” is generated for the sale to be able to complete. The actual transaction information is then stored and processed once the connectivity is available. The underlying assumption, supported by the general experience, is that the card is going to be processed, and money will be available for the given transaction at a later time.

The advantage of store-and-forward mechanism is that transactions which did not go through at the time of initial attempt can still be processed later, and, in most cases, get approved.

The disadvantage of store-and-forward mechanism is that, sometimes, once the system is operational and the previously stored transaction is reattempted, it gets declined.

The systems which support offline transaction processing have to store credit card numbers for some time. Consequently, operators of such systems need to take care of PCI-compliance and respective cardholder data storage-related issues {link}. As a result, systems which do use offline processing need to implement encryption of track data or other approaches in order to minimize PCI consequences.

Offline transaction processing is most suitable for e-commerce businesses, where a customer does not get purchased product immediately after the purchase, leaving some time for transaction re-processing. The approach is also applicable for service providers (such as newspaper subscription, dating web-site subscription) because, in theory, a service can be terminated (canceled) the next day after a customer ordered it. On the other hand, retail businesses may find it difficult to use offline processing, because once a customer gets the purchased product, it is problematic to track this customer if some transaction processing issues arise after the purchase is made. That is why retail businesses usually utilize the approach only on small amounts (usually, under $50).

There are two common scenarios for offline processing implementation. In retail businesses it is usually implemented at the level of payment terminals, while, in general, the approach can be utilized at payment gateway level as well. Some processors also offer offline processing at the level of their own payment systems. Regardless of the level of its implementation, the general store-and-forward mechanism used for offline transaction processing remains conceptually the same.

Conclusions

Offline transaction processing is a relevant solution for e-commerce businesses, experiencing communication problems with the host payment processing application.

Encrypted MSRs and Payment Terminals

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

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

From traditional to encrypted MSRs

Traditional MSRs

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

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

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

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

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

Encrypted MSRs

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

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

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

Payment Terminals and Their Types

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

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

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

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

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

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

Conclusions

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

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