EMV FAQs for developers

Transcription

1 EMV FAQs for developers You accept the Information presented herein as is, without any representation as to its accuracy or completeness. What are the three levels of EMV certification? There are three levels of EMV certification that a solution must undergo before it can be deployed. Level 1 and Level 2 certifications pertain to the terminal device and are the responsibility of the point of entry device manufacturer. Level 1 certification addresses the mechanical and electrical protocols used for transferring data between the terminal and the payment card. The device manufacturer is also responsible for receiving a Level 2 certification, which addresses the software application residing inside the device (firmware) that performs EMV processing. Once the manufacturer has achieved both Level 1 and Level 2 certification, a POS developer can then use the certified device to create an EMV solution for its POS system. The POS developer must then undergo a Level 3 certification for the complete solution. What constitutes a Level 3 certification? Level 3 certification, also called end-to-end (E2E) or network certification, tests each unique EMV path to the networks. The testing flow is as follows: Level 1 and 2 certified device, the POS application, any middleware or gateway in use, the processor, and finally out to the card brands. Each card brand has a set of defined EMV test cases that must be run to satisfy their EMV certification requirements. In addition, each processor may have their own test cases that they want POS developers to run as part of their host message certification. This process must be completed individually for each device the POS is using. What is the difference between being EMV ready and EMV capable? When a merchant is using a device that has been through Level 1 and 2 certifications, it is EMV ready. Once that device and the payment applications and systems that it is connected to have completed a Level 3 certification, the POS solution becomes EMV capable. What are the requirements for a Level 3 certification? Each unique transaction path has to be certified to each network individually, and if any part of the path changes, a new certification is needed. Examples of changes requiring a new certification include: the terminal/point of entry devices, the processor/merchant acquirer, and any middleware or gateway that is involved. Example A POS provider wants to certify with two different devices and currently works with four different processors: At a minimum of 2 terminals x 4 processors x 4 card brands = A total of 32 card brand certifications will be needed 1

2 Each card brand certification could have around 200 test cases Each processor may also have their own host message certification requirement and additional test cases If a developer chooses to do a direct EMV integration, is the Level 3 certification cost paid by the developer, or by Vantiv? It s paid by the developer. Vantiv has a test package, viable, that it sells to developers interested in doing their own certification. When would a direct integration to EMV be most suitable? This option enables the greatest degree of customization, allowing developers to choose which device you want to take through certification and how you want to configure terminal transaction flows. The drawbacks include having the longest time to market and the highest degree of complexity. It also comes with a high cost, both from development and QA resource time, as well as the purchase of the necessary test cards, kits, and tools needed to complete the certifications. We anticipate that many tier 1 retailers will look to complete direct EMV certifications to support their unique POS environments and in store business process flows. What is a semi-integrated approach? In this case, the POS is integrated to the payment application, but is removed from most of the EMV transaction flow and the complicated integration and interaction between the EMV device and chip card. In an EMV out of scope solution the transaction process flow is simplified for the POS developer. The POS initiates the transaction request and passes the purchase amount and other basic information such as the merchant credentials, to a payment application running on the POS. That payment application then communicates with the EMV device, which actually handles the transaction, then returns the necessary information back to the POS for printing an EMV compliant receipt, and for reporting purposes. What are the advantages of a semi-integrated approach? There are many benefits to the EMV out of scope solution for POS developers. Most importantly, it puts the burden of the Level 3 certification on the payment application provider. It is up to the EMV out of scope solution provider to take each device through certification with the various processors and networks. It will also speed up the time to market for POS providers, as integrating to the EMV out of scope solution is similar to the payment integration process they are familiar with. It is also cost 2

3 effective for the POS developer because the cost of EMV device integration is taken on by the EMV out of scope solution provider. However, minor tradeoffs include lack of customization in terms of the EMV devices available and a limited amount of terminal screen flows that come with EMV. How does this solution compare to a stand-alone solution? Stand-alone terminal EMV solutions are already on the market today because they are the simplest to deliver, both from a functionality and certification standpoint. The transaction path from the terminal application to the processor is shortened, which reduces the complexity of the Level 3 certification. This simplicity, however, comes with a loss of business functionality. Without integrated payments, transaction reconciliation becomes challenging, as payments capabilities are removed from the POS. Merchants may also be taking a step back from an overall security perspective if they choose an EMV capable terminal that is not capable of end-to-end encryption. Where they may benefit from the card authentication that EMV provides, they lose the benefit of protecting data in flight. Are others going to market with stand-alone terminals? In Canada, at first many developers offered stand-alone EMV terminals. They later came back to offer an integrated solution, because stand-alone wasn t meeting their needs. The feedback we heard from merchants was that they were dissatisfied with the stand-alone terminals because the payment process was not integrated to the rest of their business and caused a lot of extra work. What is the liability shift? The liability shift moves the responsibility of fraudulent transactions and chargeback from the merchant to the card issuers. This means that any transactions that are made fraudulently at a merchant location are covered by the issuers, but there is a catch. To qualify for the liability shift a merchant must process 95% of its total transactions through a certified EMV solution. This means if a merchant has its IPOS fully EMV capable, but has another device that is not EMV capable that it uses to conduct 10% of its business, that merchant is not eligible. EMV is an all or nothing proposition. Merchants are being pressured to accept EMV. However, it s very important for merchants to understand what the liability shift, which is driving EMV adoption, really means to them. Again, to qualify for the liability shift, merchants that are presented with EMV cards must process the payment via the chip even if it allows them to swipe it. If consumers are resistant to using their chip, it will decrease the merchant s acceptance rate and ultimately disqualifying it from the liability shift. What is the impact of the liability shift? It depends on the merchant demographics. For example, the liability shift may be an incentive for tier 1 merchants that have higher fraud risk, but may not be sufficient to motivate smaller merchants with 3

4 lower levels of risk. This is why initial adoption has been low in other countries. In Canada, EMV started eight years ago and it just passed 50 percent adoption this year. Keep in mind that Canada has a much simpler banking structure than the U.S., and so has less complexity. We expect the adoption rate in the U.S. to be slower in smaller merchants than larger merchants. A great source of information on EMV, including historic information and recent announcements is the EMVCo website, Is EMV a mandate? No, EMV is not a mandate for developers, dealers or merchants. The benefit to the merchant is that liability for counterfeit and lost/stolen chargebacks will move back to the issuer if the transaction is ran as EMV. Again, to qualify for the liability shift, merchants that are presented with EMV cards must process the payment via the chip even if it allows them to swipe it. If consumers are resistant to using their chip, it will decrease the merchant s acceptance rate and ultimately disqualifying it from the liability shift. Liability shift is on a transaction by transaction basis, not on a terminal or merchant basis Today all liability for counterfeit and lost/stolen falls on the card issuer In October 2015 that will shift to merchants unless they are able to process EMV cards The following chart illustrates the various liability scenarios, but many nuances could impact the liability shift: Terminal type Card type Liability goes to mag stripe only mag stripe only issuer EMV capable mag stripe only issuer EMV capable EMV, chip+sig only issuer EMV capable EMV, chip+pin issuer EMV capable, Chip+SIG EMV, chip+pin merchant EMV capable, Chip+SIG EMV, chip+sig issuer EMV capable, mag stripe fall back EMV, chip+pin Varies based on reason for fallback EMV capable, mag stripe fall back EMV, chip+sig Varies based on reason for fallback Our main POS vendor currently supports direct integration using VeriFone payment terminals, which are set up to work with the application. Will those VeriFone terminals need to be reprogrammed to use EMV? The terminals are EMV Capable. 4

5 It will depend on the terminal as well as how the POS vendor chooses to implement EMV in the U.S. Each unique solution path will need to be E2E EMV certified, from the terminal to the POS, out to the processor, and on to the card brands. An alternative approach may be to look at an EMV out-of-scope (semi-integrated) integration method. As a developer, would we have any liability if our product does not support EMV by October 1, 2015? As far as the rules and regulations read today, no. Chargeback liability for counterfeit fraud shifts to the merchant if it is not able to process the EMV card when presented at the POS. Will EMV use require the POS terminal to have a specific version of Windows? No, it will be based on the software versions of the terminals and POS systems that have been taken through the EMV certification process with the acquirers and networks. Regardless of EMV you must comply with the rules of PCI as it relates to versions of Windows. Are there plans to add compatibility or an additional rail for EMV to the current HostedCheckout options? (Ecommerce customer entry, POS with virtual terminal / E2E swiper) There is not a current plan to enable an EMV-capable terminal to operate with a POS virtual terminal at this time. According to the standards today, EMV only impacts card present transactions. Is EMV compatible with preauthorization? For example in hospitality, you have to preauthorize at check in and you capture at check out. Per the EMV standards today, no, the concept of preauthorization does not exist in an EMV implementation. Each transaction is a one-time event, driven by the cryptographic validation that occurs between the chip and the terminal. EMV will impact the way that certain verticals, like lodging and restaurants, handle their transaction processing and interactions with cardholders. We will cover this in much more detail in future communications. Because EMV hasn t been detailed (chip/pin or chip signature), will current EMV products like VeriFone 805/820 be usable when the rules are written and determined? Yes, if they are EMV ready devices that have been through Level 1 and Level 2 EMV certification, then they should be operable, but may require software or kernel configuration updates. It is also important to remember that each device will then have to be taken through an EMV Level 3 certification for all unique paths to the network (Device-POS-Middleware-Front End-Networks). I already have E2E encryption, do I have to implement EMV? There is no mandate to implement EMV, but EMV is an important part of a card security solution. Coupling EMV with E2E encryption can provide merchant with the benefits of both the liability shift that EMV brings, along with PCI scope reduction when using E2E encryption. EMV will add another level of 5

6 security with card authentication, protecting against counterfeit card fraud. Think of it this way: E2E encryption protects the card data once a transaction is initiated, EMV makes sure that the card initiating the transaction is valid. Q: How do the point of sale and the chip and pin/signature device communicate? There are multiple options for this: 1) The POS could be fully integrated with the EMV device and drive the transaction flows. That would require the POS provider to go through a full EMV Level 3 certification. 2) The POS could not communicate at all with the EMV device, having a stand-alone terminal for EMV transactions. 3) An EMV out-of-scope (aka semi-integrated) approach, were the POS initiates the sale transaction, providing basic transaction information (e.g., transaction type and dollar amount) then hands the transaction to the EMV device to drive the EMV transaction flow. Once the transaction is completed, the EMV terminal device returns the necessary data to the POS for receipt printing and reporting. We will discuss this approach in detail in future communications. EMV, EMVCo, VeriFone, DataCap, NFC, Windows and Apple Pay are registered or unregistered marks belonging to one or more unaffiliated third parties. 6