There are many common misconceptions about EMV and how it affects kiosk manufacturers, ISOs, merchants and business managers/owners. By the end of this you should have a good idea of what it takes for all of these groups to get their products past the “EMV capable” finish line.
EMV hardware manufacturers and distributors have spent the last few years focused on educating ISV/ISOs and hardware integrators that EMV is not just a matter of buying a new piece of hardware. A true solution is dependent on a marriage of hardware and software; and as marriages go it also entails a commitment.
An Independent Software Vendor (ISV) is an organization that sells or designs software solutions, and are often times focused on specific market verticals. An Independent Sales Organization (ISO) is a company that sells another company’s products or services. In the credit card industry an ISO can provide merchant accounts backed by larger banks or processors making them a Merchant Service Provider (MSP). Like ISVs, some MSPs may focus on servicing specific types of merchants.
EMV Level 1 means that a device physically meets EMV specifications for chip (contact), and in some cases NFC (contactless).
EMV Level 2 means that the firmware on a device performs to EMV processing specifications.
Both EMV Level 1 and Level 2 are the responsibility of terminal manufacturers. This hardware can be described as “EMV ready.”
EMV Level 3 is achieved when a developer marries a device, meeting the aforementioned Level 1 and 2 EMV specifications, with their software and commits to certifying it with a processor or processors and then the card brands. This fully developed and certified solution can be described as “EMV capable.”
The cost and level of commitment varies greatly depending on the developer’s goals. A developer can choose to pursue a direct certification with a processor (fully integrated) or decide to use a payment gateway which has already made a commitment to certifying a piece of hardware with a processor(s) (semi-integrated).
Below are summaries one can use to compare the level of commitment, complexity, and cost between semi-integrated solutions and a fully-integrated solution.
This system architecture can reduce cost and complexity by leveraging the point of sale and networking hardware infrastructure that is already in place. With a software semi-integrated solution a developer will use an SDK to integrate a POS software with a third party payment gateway. The SDK is usually comprised of two main parts. The first is a means for the POS application to issue commands and receive messages from the payment terminal. The other part is an isolated software agent that resides on the POS host machine, but is partitioned from the POS software itself. The isolated software agent’s sole purpose is to create an encrypted connection to the gateway switch. This allows the POS and the terminal to share a LAN connection. It also ensures cardholder account data is not “seen” by the POS software, stored on the host machine, or anywhere else on the local network. Payment Gateway’s will provide the API making integration easier and less expensive.
This solution is similar to software semi-integrated but does not use the aforementioned isolated software agent that allows the POS machine and the payment terminal to share a LAN connection. Hardware semi-integrated requires the payment device to have its own dedicated connection to the gateway switch. Cardholder account information is received by the terminal and sent on to the gateway for decryption and processing. An approval or deny message is sent back to the terminal and subsequently communicated to the POS through a local or web based API. As with the above solution, this prevents the POS from “seeing” or storing cardholder account data.
Unlike the above scenarios where a POS provider or merchant can piggyback on the PCI-DSS certification of a gateway’s semi-integrated solution; this scenario means the entire payment system is within the merchants owned and maintained infrastructure. The POS machines, the terminals, the servers, the firewalls, everything. The entire system is also within PCI Security scope. Any change in a part of the system affects the other parts. They are all connected and communicating with each other as a whole point of sale and payment processing environment. Transaction processing requests are being sent through the local network, and sometimes sensitive data is stored on local servers which is the merchant’s job to protect. This solution is extremely costly and time consuming to develop and certify, but can be beneficial if the merchant (typically a tier one retailer) is accepting thousands of credit cards a minute as it removes the initial costs of middleware and subsequent ongoing gateway fees. It is worthwhile to also keep in mind that any significant modifications to the system, like changing the model of the payment terminal, can require a completely new evaluation by a PCI Qualified Security Assessor, and call for an entire new processor certification. Additionally, it is the owner’s responsibility to keep the system up to date with ever changing security requirements and mandates.
As this page explains, it is not as simple as most people think. There are quite a few steps one needs to consider when choosing how to begin accepting EMV payments. UCP Inc. is here to help you weigh your options and get your EMV migration underway.