What is EMV? EMV, by definition, “is a global standard for credit and debit payment cards based on chip card technology taking its name from the card brands Europay, MasterCard, and Visa – the original card brands that developed it.” That definition doesn’t tell us much. Most of us understand EMV to mean chip cards that can be inserted into a slot in the payment terminal. Chip cards allow additional verification to prevent fraud in card-present transactions. They are much harder to copy than the traditional magstripe. They also have additional verification built into each transaction so that each use can’t be reused, like magstripes can be.
EMV has disrupted the industry because as of October 2016 the Card Brands (MasterCard, Visa, Discover and Amex) have required their merchants to either accept EMV chip cards, or be responsible for additional fraud liability. This has been referred to as the liability shift. This liability shift has rattled the payments industry. It’s the first time in years that U.S. merchants will be forced to upgrade their point-of-sale (POS) equipment and terminals. Vendors of terminals are scrambling to support the technology and grab more market share; merchants that are forced to buy new equipment start looking at new vendors.
EMV is bringing the US up to a standard that has been available in Europe for over a decade. It has reduced fraud on card-present transactions significantly where it has been implemented. For card-present merchants it is a must in the next couple of years. For online vendors and Ecommerce (also referred to as “card not present”), EMV doesn’t change the game at all. As more and more merchants implement EMV, we will see a shift in fraud from card present to card not present transactions.
Things to know about EMV certification
To understand different EMV solutions you must first understand the rules. Card Brands are requiring certified solutions. Certification requires testing from where the EMV data is captured, all the way through to the card issuer. Do you want to accept more than one card brand? You will have to certify with each brand you want your solution to accept. Every end-to-end solution that touches payment data needs to be certified. Do you currently take magstripe card reads and does that data go through your software solution? Get in line.
The back log just to begin an EMV certification is currently 12 weeks, and then an additional 8 weeks of running transactions and testing. If you think you can go in with all your code pretested and just run your scripts, you might want to think again. Many of the card brands and other acquirers are not as agile as the rest of the software world. They don’t open their EMV test environments until you have started certification, so there is no way to accurately test your code prior to the start of certification. This increases the time it takes to complete certification.
Dealing with the different card brands can be difficult. A change in one component can require a restarting the entire certification process. Are you scared yet? Does that sound awful? The more I learned about certification of the EMV process, the more I tried to think of ways to avoid it. And also, how our customers could avoid it altogether.
If you are going to rewrite the payment portion of your software to support the new EMV specifications, it might be a good time to think about how to reduce your PCI scope. For those of you who are new to payment software, The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment. Depending on how much card data your system touches depends on how much scope an audit will touch. And you guessed it, the larger the scope, the more expensive the audit. To reduce your PCI scope means to reduce or eliminate the amount of card data that pass through your software solution. Wouldn’t it be great if while tackling EMV you could reduce your PCI scope at the same time? Below is a Matrix that shows the different options for integrating EMV and its impact to PCI and EMV certification.
|Approach||Description||PCI Implications||EMV Implications|
|Fully Integrated||The POS interfaces Terminal for EMV only. This solution gives the POS developer the most control of the transaction process.||PCI is in scope for the POS as the POS handles card track data.||An EMV certification is required on the complete solution|
|Partially-Integrated||The POS interfaces with the terminal for EMV functionality. The POS provides the actual host connectivity and is responsible for transmitting and receiving host messages and storing the authorization data.
|PCI is in scope for the POS as the POS handles card track data.||An EMV certification is required on the complete solution|
|Semi-Integrated||The POS interfaces with a Terminal for host connectivity as well as EMV functionality. This solution eliminates much of the POS development as the POS does not build the authorization message.||PCI is not in scope for the POS as the POS does not see the card data||An EMV certification of the complete solution is not required as the Terminal handles all the card data and only passes back the authorization response.|
Multiple Ways to Work with Clearent’s Payment API
As a good payment API, we want to support our merchants and developers and allow seamless, easy-to-use solutions. Our goal in implementing EMV is to take the complexity out of the solution so developers can focus on their product, not their payments.
Clearent provides multiple ways to develop to our payment gateway. We provide a payment API for fully integrated solutions for developers wanting full control of their POS design. We’ve also partnered with Dejavoo and PAX to provide a semi-integrated solution for developers looking to avoid PCI scope, and take EMV payments without having to undergo the certification process.
For our Semi-Integrated solution with Dejavoo, developers will integrate to the terminal interface, which will work with our API to provide payment authorizations. As a POS developer, you will send all your necessary data (minus the card data) through an API call to the terminal (amount, invoice number, etc.). The terminal will listen for your request. When it gets the request, it will wake up and ask for card data. Once the card data is inserted, the terminal will make the downstream call to Clearent for the authorization approval. Once that is received, the terminal will send the response back to the POS system. This approach allows all card data to bypass the POS, reducing PCI scope and taking the POS out of the EMV certification process.
My Recommendation: Semi-Integrated Payment Solution
Developers can also use the Clearent Semi-Integrated Solution as a standalone EMV terminal, while still taking advantage of our other payment gateway features and reporting.
<rant>As a developer myself, if I was thinking about building a POS software solution, I would go with a semi-integrated choice. I would not want to have to certify my solution at every change. I also would not want to have to deal with the long waits of EMV certification. After learning about the EMV certification process, all I can think is GROSS. GROSS that you can’t have your code integration tested prior to running certification scrips. GROSS that you have to deal with timelines longer than it would take to develop the solution. Just GROSS. We at Clearent have worked hard to develop a continuous delivery pipeline and strive to be very agile delivering for business needs as quickly as possible. Waiting in line for EMV certification in this day and age of software development just blows my mind. If I had a choice, I would absolutely integrate to a semi-integrated solution. </rant>
All the payment industry requirements such as EMV and PCI can add complexity for any developer. Clearent works to minimize these impacts to your business and application to provide creative payment solutions so that you focus on your business, and we will take care of your payment solutions.