If you’re just joining us, be sure and read the first part of this series: Step 1 –Hardware Requirements and Environmental Requirements Analysis where we review the physical requirements of the hardware needed for EMV acceptance. In this second in our series of four, we will explore the various software changes that are required throughout the ecosystem in order to facilitate EMV card processing.
Step 2 – Software Changes and the Impact on Merchants:
The software side of implementing EMV implementation is going to be largely out of the hands of most merchants using a commercial POS system that includes payments processing. While the payment system software is likely not something a merchant will have direct control over, the components that will need to change should be understood such that appropriate cross functional planning can occur.
First and foremost, the card accepting terminal will need to have the appropriate software on it in order to interface with the EMV cards. As with the hardware, this interface from the card to the terminal requires a certification, in this case EMV Level 2 Type Approval. This information can be found here on the EMVCo site.
Continuing the discussion in regards to the card accepting terminal, the terminal will also need to have the current software application for the various card brand products. Since this is a completely new concept to the US market, I will explain quickly.
As mentioned above, Visa, MasterCard, and Discover all have taken different approaches to the US market. As such, while their cards will physically interface to the terminals in the same manner, they will have different functionality (e.g. one may require a PIN and another may not) and thus will require unique applications, called kernels, to handle the various brand’s functionality. Thus a terminal that accepts Visa, MasterCard, Discover and American Express EMV cards will have four kernels, one for each card brand, in order to accept and process each card brand.
Initial deployment of the kernels is likely to take one of two different approaches. The first and simplest approach would be the deployment of the kernels along with the initial deployment of the hardware. This would be the case where a merchant buys and installs hardware after all of the brands have launched their programs and thus have made their kernels generally available to the deployment community.
The second and more likely approach for most large merchants would be the deployment of kernels after the hardware has been deployed in the field. This would be the case for merchants that need to or want to replace equipment before all of the brands are ready with their EMV packages. In this case, merchants will need to have implemented a method for the card accepting devices to receive software updates. This can occur through maintenance and support programs like VeriFone HQ or through other deployment options either directly through a download service or via an integrated POS system that has the ability to send files to the in-lane devices.
“To be clear, it will be the responsibility of the merchant to appropriately maintain the EMV software and the then current kernel set.”
A further note on the EMV interface software and kernels – they can and do change over time and adoption of these changes in a timely manner is required in order to continue accepting EMV transactions.
The point here is that any EMV implementation plan should include specific direction for addressing maintenance of these software components. If acceptance of NFC payments or programs is in your future, the ability to remotely maintain the card-accepting terminals will be a key ability. Each of the NFC wallet programs requires the equivalent of an EMV kernel to be running on the device, hence the ability to update or add new NFC ‘kernels’ is a key future proofing ability.
As terminal application management will impact technical operations and operating expense, talking to your partners earlier rather than later regarding ongoing management will eliminate some of the surprises later on.
Moving upstream from the terminal to the POS, the interface from the card accepting terminal to the POS will also need to be updated to handle the new data elements presented in an EMV transaction. Further, the POS to gateway, switch or acquirer will also need to be updated to handle these data elements as they have simply not been required in the past. Merchants who operate their own payment switch or gateway should take special note of this section as they will be the ones impacted the most.
Finally, acquirers, gateways, and switch providers will all have to update their systems and interfaces to support the new data elements. For acquirers, support for this functionality is mandated by April of 2013.
Building out a virtual Gannt chart, the critical path is initially going to be on the acquirer or payment processing host to provide an interface spec and working interface to the POS provider. The POS provider will then have at least two development projects: Network Interface Update, and Card Accepting Terminal Interface Update. Finally, the card accepting terminals will need to be updated or provisioned with the appropriate software and kernels.
As you can see from this discussion, there are several moving software parts and some new requirements for the operation of card accepting terminals. Having a holistic view of the external and internal changes required will ultimately help facilitate a more robust EMV acceptance implementation plan.
In the next post we will provide an overview of the changes to the payment system certification process associated with EMV card acceptance.