You have probably noticed that your credit cards now have little chips in them. You may have already used them at stores by inserting (or “dipping”) them into the card reader instead of swiping. While waiting for the transaction to complete, did you wonder what’s taking so long? Perhaps you tried dipping in some places, but were told “that doesn’t work yet” - did that make you wonder why? Keep on reading to find out.

The construction and interaction of chip-based smart payment cards with payment terminals is governed by a technical standard known as EMV. It is named after the the three companies that originally created the standard - Europay, Mastercard, and Visa, but is now managed by EMVCo, a consortium of the largest payment card networks in the world. The standard defines the technical specification for chip cards and terminals that will interact with the chips. It also defines the communication protocols used during the interaction.

Card reader and chip card

Fig. 1: A brandable WePay card reader (left) and a test chip card (right)

Why EMV?

Compared to traditional magnetic stripe technology, EMV offers significant benefits for both terminals and payment cards by improving security and allowing greater flexibility. The security comes from the smart chip that dynamically generates single-use payment data. It eliminates the most common fraud vectors of man-in-the-middle and replay attacks and makes counterfeiting harder and more expensive. The standard allows for additional security against lost/stolen cards by requiring the cardholder to enter a PIN code for each transaction (chip-and-PIN), but unlike European countries, most card issuing banks (issuers) and merchants in the US have chosen to forego this option in favor of signature verification (chip-and-sig). Additionally, issuers have chosen to not support “offline” transactions and instead require terminals to always go “online”, giving the issuer full control over each transaction. This does mean that unmanned terminals such as ticketing and vending machines cannot accept chip cards without a connection to the internet.

In spite of the benefits, EMV did not see much adoption at first, largely due to the cost and complexity of implementing the standard. To encourage adoption, major card networks in every geography enacted liability shifts - selected dates when the liability for card-present fraud shifted to either the issuing bank or the merchant that did not adopt the standard. If both parties adopted EMV, then the liability for fraud rested with the issuing bank, same as with traditional magnetic stripe transactions. Visa, Mastercard, Discover, and American Express implemented the liability shift for point of sale terminals in the US on October 1, 2015. This triggered a wave of adoption across the country, with over 70% of card holders now having a chip card. However, adoption with merchants remains slow, with most estimates of merchants accepting chip cards falling in the 25-35% range.

What is so hard about adopting EMV?

EMV’s enhanced security and greater flexibility make it an inherently complex standard. The full EMV specification spans four books totaling over 700 pages. In comparison, the process of performing a traditional magnetic-stripe transaction is quite straightforward:

Card reader and chip card

Fig. 2: Magnetic stripe transaction flow

The EMV transaction flow is more involved:

Card reader and chip card

Fig. 3: EMV transaction flow

The chip can contain multiple payment “applications”, such as several different debit or credit cards. The terminal must be programmed with every single application it can accept. The terminal must also show the list of applications available on the chip to the cardholder, and allow the cardholder to choose the application ID (AID) to be used. Next, the terminal must request authorization from the chip. It is possible for the chip to approve the transaction right then (in vending machines, for example), but in the US the chip will always respond with a request to go online. The terminal must then gather card information (including a request cryptogram that can only be understood by the issuer), and request authorization from the issuer via the card network. The issuer may decline the transaction, or send a response cryptogram back. The terminal must pass on the cryptogram to the chip, which verifies the issuer’s response and makes the final decision about authorizing the transaction. The chip then provides the third and final authorization cryptogram to the terminal, and the merchant must use it for settlement of funds. Additionally, as part of the authorization response, the issuer may return updates meant for the chip, and the terminal is responsible for ensuring that the update is delivered to the chip.

The process of implementing the spec is also complex. The dynamic nature of the transaction makes it very difficult to mock the various systems during development. Terminals can only interact with real chips, and real chips only work with authentic cryptograms for transaction processing. The many different data and decision flow paths result in a multitude of possible scenarios that must each be tested.

How did WePay implement EMV?

WePay’s Mobile Point of Sale (mPOS) program is meant for our partners who have mobile apps and want to provide their users with a way to process card-present transactions. We have partnered with a hardware provider who manufactures the card readers and provides iOS and Android SDKs for communicating with them. We have created our own mobile SDKs that handle communication between the hardware and the card network. We abstract away most of the complexity of the EMV standard and provide a much simpler interface to our partners, who in turn expose this interface to the users of their mobile apps.

The (simplified) development setup looks like this: Card reader and chip card

Fig. 4: Development setup diagram

For development, we had to mock our servers, our partner’s systems, and use a development kit from our payment processor. The kit consists of development chip cards and a development reader that could re-program the cards for various test scenarios. The kit also came with mock issuing bank and payment processor server software that we had to deploy in-house to have control and visibility over the entire transaction cycle.

Card reader and chip card

Fig. 5: Physical development setup

Testing and certification

After development, the next steps were testing, validation and certification. After discussions with our payment processors about the capabilities of our card readers, the features we support, and the card network requirements, we were given a list of over a hundred scenarios from the four major card networks that we support. To run each scenario, we set up the mock issuer, programmed the card, and configured our test app with the test parameters. We then executed the transaction, tracking the requests from the card reader (via our SDKs) to our dev servers, then onto the processors and all the way to the mock issuer. The mock issuer verified that the request matched the test scenario, and returned a response. The response was routed back to the card, which verified the response, and issued the final approval/denial code. We then placed the card back on the test reader where the mock issuer read the card logs to determine if the card had behaved as expected. If all went well, the test was marked as successful, and we moved onto the next test.

One interesting social issue emerged due to the fact that our card reader beeps pretty loudly at the start and end of each transaction. We endured around five thousand beeps over the duration of this project. To save ourselves from the ire of our co-workers, we had to resort to some creative solutions such as building a sound-proof box (pictured above) to temporarily house the phone for each transaction, performing tests in isolated rooms for entire days, and working during odd hours.

We were one of the first companies in the world to use this particular setup of the testing environment, and so we encountered a number of issues which turned out to be a problem with the test kit itself, and not with our implementation. For example, the mock issuer would sometimes return invalid data, and the test case would fail because the result was invalid. To pass the test case we had to report the issue and wait for a fix, then re-run the test case and verify that the fix worked. When we encountered issues with our reader or its SDK, we had to install firmware updates on the reader or get updated readers to pass the failing test cases. This whole process of testing, discovering, debugging, fixing and re-testing resulted in us running each test case roughly 30 times on average.

Final certification required us to run all hundred-plus test cases successfully in a two-day window. The resultant logs were first verified by our processor and then sent to the card networks. The four card networks then independently approved/rejected the test run. Our first submission was approved, and we received our EMV certification roughly 12 months after first starting our implementation. To put this into perspective, it had taken us just two weeks to get certified for magnetic stripe transactions.

Conclusion

EMV transactions are more secure, more flexible and much more complex when compared with traditional magnetic stripe transactions. Merchants transitioning to EMV incur significant costs for hardware, along with time and resources for implementation and certification.

Fortunately, most merchants will not have to deal with the whole implementation alone. They can utilize services from companies like WePay, which can do most of the heavy lifting associated with implementation, and expose simple interfaces for merchants to use.