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.
Recommended to you
