HCE BLE EMV is a new way to pay

There has been a lot of discussion about using Host Card Emulation (HCE) to support EMV payments over Near-Field Communication (NFC) interfaces. But HCE can be used to support EMV payments over, essentially, any interface. As part of Consult Hyperion’s prototyping programme, we developed a working (ie, using EMV data) proof-of-concept demonstrator (running on Android and iPhone) for paying with HCE over Bluetooth Low Energy (BLE) and showed it at the UK Cards Association last week. The demonstrator is so cool it superconducts.

Most of you know Consult Hyperion as the consultancy of choice for organisations who want to exploit new technology for mass-market electronic transactions. But you may not know that for many years we have had our own full-time, in-house development team. We call this the Hyperlab, and it’s a resource used by many of our clients to build prototypes and proof-of-concept demonstrators, to play around with new ideas and to try out new technologies to see if they might be useful in market-market deployment. As you might imagine, one group of technologies heavily used in Hyperlab at the moment are NFC, SE and HCE. But in recent months, there’s been some experimentation going on with BLE. It’s not relevant to say why or for which clients, but we have good reason for thinking that BLE will be taken up by many of clients to support new customer experiences.

The question naturally arises, then, as to the relationship between the technologies in this group. Our clients are at the larger end of the scale, so when they invest in new technology (even if it is only for prototyping) they need to have a view of the roadmap with a path (or more typically, paths) to connect the technology push with the business pull in a sensible manner. To be specific, the question facing many of our clients is the choice of path connecting all of these technologies in the retail environment. Largely because of the dominant position of Apple in the mindspace, if not the marketspace, a lot of recent discussion has been around the pros and cons of NFC and BLE, which I think is in many ways an unproductive place to begin the conversation. And I am not alone.

NFC and Bluetooth Low Energy (BLE) will likely complement each other and coexist in the mobile ecosystem because their best use cases differ, John Ekers, the CIO at ABnote said in his keynote presentation.

[From American NFC Mobile Technology Adoption to be Spurred by the ‘Big 3′: HCE, BLE and EMV | RFID Technology News (Radio Frequency ID)]

I think John’s right about this and we have been advising our clients the same for a good while. In fact, as I wrote last year, there is no need to see any either/or in the combination. Some people like to tap. Some don’t. Some people want to use a mobile wallet. Some people want to use a retailer app. Some people like to be recognised automatically. Some prefer to have control. So let them have their choices.

An HCE/NFC/BLE world seems rather attractive from a consumer experience perspective.

[From Why all the fuss about HCE? – Tomorrow’s Transactions]

Now, since the nature of our business concerns transactions, we are particularly interested in the technologies around retail transactions. And since most of our clients have in recent memory spent an enormous amount of money migrating to EMV, it is naturally of interest to see how this transaction technology works with NFC and BLE. With this in mind, and in the context of a couple of projects we are working on, we thought it would be interesting to see if we could execute EMV transactions over the BLE vicinity interface. Obviously we know how to do this using the NFC proximity interface, and so does everybody else, but there are a couple of good reasons for trying it over BLE.

• First of all, both Android phones and iPhones (and also other phones, and for that matter smart watches and the like) have BLE whereas they do not have NFC. This means the retailer app can deliver a common experience on both platforms. Since retailers want to use BLE to establish communication between location and customer, using it for payment as well is an obvious extension.
• Secondly, a rich BLE interaction between the handsets and the point of sale or service can encompass coupons, loyalty, offers, information and all sorts of other valuable data as well as the payment data.

So we tried. And it worked. Really well. Here’s Stuart Fiske, our CTO, showing you. The laptop in front of him is running the POS software and it has a BLE USB diongle connected. The power on the device has been dialled down to reduce the range (important for POS applications). Stuart is running a mobile wallet app on an Android phone. This app has real EMV credentials stored in it and will use HCE to pretend to be an EMV card to the POS terminal.

(There’s nothing secret about this, by the way. It was demonstrated by our chaps at UK Cards last week.

The POS writes a payment request to the BLE dongle. This request contains the EMV data fields that are needed to effect a transaction with a standard EMV card. The request is broadcast and picked up by the mobile wallet app. The app takes the data fields and feeds them to the HCE app, where the relevant EMV jiggery-pokery goes on and a bunch of data fields are generated. These are fed back to the POS terminal, where the EMV data elements are stripped out and passed on to the acquiring system. Note that the acquiring system has no idea that these data elements came from HCE via BLE: all it sees are the same EMV data fields that it would see in a normal interaction with a standard EMV terminal.

The transaction is approved, and the customer has paid, securely, while standing near a POS terminal or POS person or mPOS or vending machine or… You get the point. It’s cool. And here’s the fun part: here’s the same app running on an iPhone. Yes, that’s right. HCE on an iPhone, but using BLE instead of NFC to pay.

And just in case anyone wants to check the cryptography, here’s the details of the message back from the acquirer!

Just as a further point, you can see how this might work with tokenisation. The iPhone/Android bank/retailer/whoever app would periodically contact the relevant token vault to pre-fetch tokens valid for an hour or a day or a particular merchant. Then, when the customer walks into the branch/shop/wherever, the app opens up and displays coupons, loyalty points, shopping lists and so forth. The customer gets what they want, it gets rung up either at a conventional POS or on a handheld POS. Then the consumer executes an EMV payment either by tapping with an NFC phone or confirming on a BLE phone. Either way, it’s a secure transaction that uses the standard EMV infrastructure to deliver to terrific payment experience in the context of a terrific shopping experience.

Our Hyperlab guys rock.