The Challenge of Delivering mPOS Services through Off-The-Shelf Mobile Devices

Greyscale backing image

 

The last few months have been exciting if, like Consult Hyperion, you are attracted by the mobile POS (mPOS) sector. We’ve seen significant announcements from Mastercard and Worldpay and heard interesting rumours about the current work within the PCI Security Council, suggesting that the use of off-the-shelf mobile devices as card acceptance devices is likely to happen in the near future.

Targeted at small to medium sized and mobile merchants who do most of their business in cash or cheques, but have the occasional customer who prefers to transact by card, the mPOS dongle (card reading device) has been seen by these merchants as their first venture into the “expensive” world of credit and debit cards. However, the cost of the dongle and the power required to run it are often cited as barriers to the adoption of mPOS services.

Magnetic stripe dongles are effectively given away; their cost refunded through reductions in the fees levied against the initial transactions; their power derived from the phone, when inserted in the audio port. Chip & PIN dongles are more complex and so more expensive requiring their own power supply or battery. The business case to subsidize the additional cost of these devices through reductions in transaction fees is more challenging.

The higher cost and more power-hungry elements of a Chip & PIN dongle are the display and keypad. If we can replace these components with the capabilities of an off-the-shelf smartphone, can we bring down the cost and power requirements of the Chip & PIN dongle closer to that of the magnetic stripe version? If we can deliver the service entirely through a mobile application, can we simplify our distribution channels? These are the sort of questions that get the team at Consult Hyperion excited as they present big information security challenges, which we like.

Generic, off-the-shelf mobile devices have none of the physical and electronic countermeasures designed into a payment terminal to secure the personal and account information in the payment transaction. Nor do they have the specific assets required by the payment scheme such as the secure PIN entry capabilities. Equally, the Acquirer doesn’t have any control over the other applications loaded onto the phone or tablet, which could include malware designed to impact the performance of their mPOS service or monitor any communications to or from it.

So, the challenge is; can we develop applications for generic off-the-shelf mobile devices that deliver, as far as practical, similar levels of security to the hardware in the payment terminal, whilst withstanding repeated attack from hackers interested in capturing assets that they could use to attack the payment schemes’ international networks?

There are many companies delivering solutions which could protect the mPOS application against some of these threats and/or give the Acquirer a level of assurance about the identity of the individuals involved in the transaction. However, no one solution is likely to deliver against all of the PCI’s security standards, should they be published, and not every solution works on every mobile device.

So, the team designing your mPOS solution for off-the-shelf mobile devices must understand in detail the threats to which the application will be exposed, the most cost-effective countermeasures against those threats, how they work together and how they need to evolve in response to new fraudulent attacks. Experience would suggest that they will need to understand in detail the operation of the EMV payment application, transaction security and the smartphone operating system, whilst having considerable experience of implementing the best-of-breed information security tools.

People with such experience are few and far between. Many are my friends and colleagues, which makes my job interesting, exciting and rewarding. It looks like a busy end to the year!

#Cardmageddon in Woking

Greyscale backing image

Well. How about that. You could have knocked me down with a feather. Blimey. And so on and so forth. Check this out…

 Woking! Contactless!

Yes. It’s true. The Southwest Train ticket machines have finally gone contactless, and only a decade after I first used an NFC phone to pay for something I was able to use an NFC phone to buy a ticket in the machine at Woking station.

Woking! ApplePay!

Now, let’s be clear. Woking is no stranger to contactless. Within the town boundaries, a wallet is an unnecessary accoutrement. I suppose some people might want to use cash, cheques or cards for cultural reasons, much as hipsters insist on using vinyl records, but they no longer need to. Indeed, only yesterday when my good lady wife asked me to pop to the shop to pick up a few baking essentials, I jumped on my bike and set off, never giving a thought to wallets or wads. I had my phone set to Planet Money and that was all I needed.

On the few and far-between days when I am working at our office in Guildford I don’t need a wallet. When I’m working at home I don’t need a wallet. But when I am working in London I do. Or at least, I did. The two hurdles to handset happiness were Arriva buses and Southwest Trains. But a couple of years ago, Arriva launched their mobile app so I don’t need cash for the buses any more. The only remaining barrier was Southwest Trains. But it’s all different now. I bought my train ticket with Apple Pay for the first time today. In Woking station, if nowhere else, it was #cardmageddon.

What? Don’t Southwest Trains have a smartcard you say? Well yes, they do. But you can’t use it to buy tickets online. You have to go to the station and tap it on the ticket machine and then put in your payment card and then tap it again so it’s hardly worth bothering, especially since I need to press the receipt button and wait for a paper receipt anyway.

May 2017 will be as famous as a September 1958 (the Fresno Drop) in the history of the inexorable march to cashlessness. For this is when I went down to Woking station, after a couple of weeks’ globe trotting, to discover that everything had changed. I am living in a new world. The ticket machines at Woking station now have contactless! I can now leave my wallet at home for good!

ODA is a good thing, and not only for transit operators (are you listening USA?)

Greyscale backing image

Following the success of Transport for London’s (TfL) Contactless Payments program, a project Consult Hyperion have contributed to since 2008, transportation agencies around the world are following TfL’s lead looking to bring the same convenience to their own customers. Operators are migrating from a world where customers have to exchange real money into transit money before they can ride on a bus or a subway, to a world where you simply tap your bank issued contactless credit or debit card on the transit reader.

The Problem

As brilliant as this new world of transit payment is, it does expose the operator to some level of risk as well as deliver a variety of benefits. I’ll address other risks and benefits in later posts, but for now I want to focus on the risk of accepting a counterfeit bank card in exchange for free travel.

Of course, the benefit of accepting payment cards for transit is that you can reduce the cost of card issuance through using the card customers already have in their pocket. Customers benefit from being able to pay for transit the same way they make other retail purchases every day. With this approach you get the additional benefit of payment card security and you don’t have to rely on proprietary cryptographic techniques that could one day expose your system to fraud. Easy, right?

Well, it’s not quite that simple.

While bank chip cards come with a toolkit of security options for card issuers to use, the majority of issuers of EMV cards in the US today have only implemented one of those options required for the domestic online-only market.

To understand the issue, remember that all EMV cards generate a unique code called a cryptogram which only the card issuer can validate. So for each transaction, the card details and cryptogram are captured and sent for direct verification with the card issuer, who returns a message to accept or decline the transaction to the merchant.

However, this ‘online-only’ option is not suitable for transit operators.

One issue for transit operators is rate of customer throughput. In cities looking to implement open loop payments for transit (the acceptance of EMV cards), there is a need to handle large numbers of passengers passing through the subway gates or boarding buses.  There is not enough time, in this fast moving environment, to wait for each transaction to be authorised online by the card issuer, and there are genuine health and safety risks to slowing down people moving through the system. Hence the strict time limits on transactions:

[Shashi Verma, TfL] said “contactless cards could now deliver transaction times in under the crucial 500ms at which longer queues begin to form”.

http://www.telegraph.co.uk/technology/news/10990294/Tube-to-adopt-contactless-payment-cards.html

“Agencies who have carried out NFC pilots argue that a device must have a transaction time of less than 500ms to be viable, and prevent passenger delays at turnstiles.”

http://www.masstransitmag.com/blog/10615616/nfc-the-mass-transit-payment-revolution

Looking at the how the transit transaction times break down in detail, we find that:

  • There is some time spent by the reader to detect a card and determine what type of card it is. This should take in the order of 10ms but may increase if different card technologies are accepted at the transit reader
  • Then there is a longer period of time where the card and the reader exchange some data that typically takes anywhere from 300 to 400ms on contactless bank cards currently-issued.
  • Finally, the typical times for a card issuer authorisation that we have observed are anything from 500 to 2000ms.

As you can see, adding these times together we are well over the 500ms target the transit industry is seeking.

Now, transit merchants could take the risk on one transaction and check with the card issuer that everything is ok with the card while the customer is making their first journey. If the issuer declines the transactions, the transit operator could put the card on a hotlist to prevent further travel. Seems reasonable? The trouble with this is there is an opportunity for the intrepid fraudster to develop a simple mobile application that looks to a contactless reader like a normal payment card, but in fact, for each transaction, generates a new identifier that will sidestep the transit hotlist.

How Offline Data Authentication helps

There is another option available to card issuers in the EMV toolkit that helps the transit operator meet their 500ms target and also mitigates the risk from counterfeit cards – Offline Data Authentication (ODA). ODA is a method that allows the reader to determine the authenticity of the card and the card issuer using the cryptography provided in contactless bank card chips and readers. Using ODA has the following effect on the transaction time, now that we don’t need to go check with the issuer to authenticate the card:

  • As before, the time to detect the card and allow the card and the reader to exchange data remains the same, about 310 – 410ms
  • Now, the time to carry out ODA now adds around 50ms, meaning a new total transaction time of 360 – 460ms

This meets the 500ms target.

It’s time for ODA to be mandated for all Contactless

Contactless bank chip cards personalised with ODA, as mandated in most payment scheme regions, allows transit operators and other merchants alike to mitigate transaction risk by authenticating the card offline. If transit operators can prove the card is genuine and not on their own hotlist, they can open the gates or let the customer on the bus. The next step for the operator will be to get card issuer authorization while the customer is making their first journey. Now they have all the information they need to decide if the customer can make the second journey or not.

While transit operators in established contactless bank chip card markets (outside the US) can introduce open loop payments safe in the knowledge that contactless cards are all going to be supporting ODA, in the US, the picture is less than clear. Migration to bank chip cards is still in its first year, there are very few contactless card products issued and mobile payments such as Apple Pay and Android Pay represent the largest use of ‘contactless’. While transport operators are looking to accept contactless bank cards, they cannot risk doing so until the US domestic cards are ODA capable. If the card brands and US banks want a slice of the US transit market ODA must be at the top of the to-do list.

(By the way, ODA is not just beneficial for transit operators; there are other merchants where this technology can also be helpful. For example, following a natural disaster where communications go down but merchants still need to keep trading to ensure essential supplies get to the right people, or merchants who wish to offer quicker processing at peak periods).

The solution at TfL was simple and effective. If a contactless bank card is presented that does not support ODA, it is rejected and the customer is not allowed to travel. When ApplePay was launched in the US, not all implementations supported ODA and these were also rejected at TfL gates. By the time ApplePay launched in the UK, this problem had been fixed. From a customer support perspective, the US needs to be in a position where all cards have ODA and not just some. Transit operators don’t want to block brands (but could do to avoid confusion). It will be impossible to put a message across to customers that some can use the system and others can’t due to something obscure and technical like ODA!

Beacons in Transit

Greyscale backing image

You’ve probable heard about Bluetooth Low Energy (BLE) Beacons being used to help the visually impared navigate on their own around public transport systems. This has been trialled in Bucharest on buses and in London Underground. These are examples of relevant information being pushed to users’ smart phones based upon their location. Other similar use cases might include telling passengers when they are approaching the stop at which they plan to get off, or telling them that their selected vehicle is about to arrive.

The use case I am more interested in is the one that allows passengers to travel without paying upfront and be charged afterward based on the journey that they took. We implemented this with TfL in London using contactless bank cards and it has become known as ‘Aggregated Pay As You Go’. This works well, but relies upon the passenger rembering to ‘tap in’ and ‘tap out’ to mark the end point of each leg of the journey in order that the back office can calculate the journey taken. Appropriate charges are made to the passenger’s bank card account at the end of the day.

Beacons could be used in implementations for this use case. Such a beacons trial is to be carried out in 2017 in West Yorkshire as part of the Transport for the North’s Integrated and Smart Travel (I&ST) programme.

The aim is to automatically determine the bus journey taken by the passenger and charge on a PAYG basis. Therefore, we need to know accurately where the passenger gets on and off the bus. This information will be determined by a smart phone app by interacting with beacons and sent to the back office where the charge is calculated and payment taken.

The trial, commissioned by West Yorkshire Combined Authority (WYCA), will be used to determine:

  • whether the passenger experience is favourable;
  • whether BLE technology can deliver sufficient location accuracy; and
  • how the journey timestamp and location information sent to the back office in such a way that can be trusted and not open to fraud.

A funny thing happened on the way to the Forum

Greyscale backing image

The Tomorrow’s Transactions Forum, that is. I arrived in good time (it’s always best to add on a few minutes to give yourself time to buy a ticket) for the 7.39 Flying Glacier to Waterloo via Misery and Degradation. 

 

Of course, Woking station has changed a lot since this picture was taken. There’s a Flying Coffee Bean on Platform 2 now.

Hurrah! When I got into the ticket hall I discovered that they have installed machines to allow you to pick up a ticket that you have purchased online. Great. I have the excellent The Trainline app on my iPhone and it is integrated beautifully with Apple Pay. So you look up the tickets you want, hit “Pay with Apple Pay”, thumb it and away you go. When you get to the station you just thumb it again and tap your iPhone on the machine, it shows you the list of tickets you have purchased, you choose the ones you want and hey presto your tickets pop out.

Brilliant.

Except it isn’t. The machines don’t work this way. You have to take a payment card with you and insert it into a slot and then type in a confirmation number that you were sent by e-mail. It’s actually quicker just to go to one of the other machines and buy your ticket in the usual way.

Joined Up Thinking (Not)

The new machine on the block.

I don’t get it. Surely the Apple Pay token used to buy the ticket can be matched to the Apple Pay token presented at the machine? You should only need to put the card in if you’re forgotten your phone or it is out of battery (and even then they should do it by implementing PARs properly).

Surely South West Trains, when they were planning these machines a few years ago, had at least heard about mobile phones even if they hadn’t actually seen any. And surely they had noticed that something was going with contactless technology? Perhaps one of the South West Train’s Executive Board had overhead their servants talking about “tapping” cards to ride the bus in London and never asked what they meant? Or did they just take it be a some new lingo below stairs, a slang term for writing out a cheque?

They must just have thought that contactless was something happening to other people.

This left me wondering if other train-like options are adopting contactless. I thought I’d give it a try at Heathrow, so I downloaded the Heathrow Express and tried a couple of times to buy a ticket to see if I could use Apple Pay, but the app asked me to scan in my credit card (presumably for some hello-1996 card-not-present transaction) then crashed, so I never to got to see it in action.

So much for joined-up thinking. The whole world is moving to contactless and mobile and the most up-to-date technology on the newest machines installed (I see they got rid of the machine for connecting by video link to customer service) is the decade-old chip and PIN reader. Come on.

Queue at Woking

OK, so sometimes there’s a bit of queue.

Why can’t we buy our tickets on our phones while riding the bus on the way and then just tap and collect when we get to the station?

The only improvement in the ticket purchasing experience at Woking station since it opened on 21st May 1838 — you still stand in line, they still take cash, they still give paper tickets — is that you no longer have to fill out a “reason to travel” form, and I wouldn’t put it past Theresa May to have these re-introduced in time for the next election.

Don’t judge mobile payments by the way they work now

Greyscale backing image

A few people tweeted and e-mailed to point out how app-centric commerce can be perversely annoying, citing the example of car parking given in this recent British newspaper piece.

The competitive marketplace for cashless parking has resulted in a fragmented and rather irritating experience for motorists

From Cashless parking was meant to make life easier for drivers but our phones are awash with competing apps | Features | Lifestyle | The Independent

Well, I don’t know if I’d go so far as to say “awash”, but I take the point. I’ve got RingGo and PayByPhone on my iPhone right now. I use RingGo the most. It’s super easy and convenient, except for the hello-2013 bit about paying. Although it’s on an iPhone, it doesn’t use Apple Pay. So I had to sod about typing in my credit card details when my new card arrived and every time I use RingGo I have to remember the three digit code from the back of the card (which I do, to be fair, a good four times out of five). If you want to know how an app should work, check out the new Trainline app.

Trainline Pay

Select Apple Pay, thumbprint, done. Why isn’t all in-app purchasing like this. Come to that, why isn’t all purchasing like this. Actually, it soon will be…

Apple Pay is already available to use in stores and on your phone in apps where it’s supported. Now it looks like the service could be expanding to Apple’s Safari browser, making it possible for pretty much any website to add the mobile payment service as a checkout option.

From Apple Pay said to hit the Web soon

I share the writer’s frustration that when you load a new app to do something straightforward like buy a bus ticket or park a car you have to mess about typing in all of your details, getting out your credit card and typing your financial information back into the phone for the 100th time, searching for the app when you need it and all the rest of it. But that’s because all of this stuff is currently built on yonks old web crap. Look at this screen, for example. Why is the Arriva app asking me for this? Why doesn’t it ask my Barclays app? Or use Apple Pay? Or just remember what I typed in last time?

Untitled

As the example of the Trainline shows, when you build an app properly using the infrastructure that is growing up in the mobile world then it’s a different story. What should happen when you walk up to the car parking machine is that the app should be fired up automatically either because of Bluetooth beacons in a car park or some other kind of geolocation service, and if you don’t have the app you should be given the option of downloading it quickly and conveniently there and then. When you run the app for the first time it should just look and see if you have Apple Pay or Android pay or Barclay Pay or Chase Pay or Walmart Pay or Lego Pay or PayPal or whatever else pay and ask you which one you want to use. End of. And when you want to use the app you should never have to put up with the sort of nonsense I do buying a bus ticket, standing in bus queue trying to type a PAN into a small screen using a tiny keyboard.

“But if you are an online service provider of any kind – whether you are Waitrose or Airbnb – you want to provide the best experience for the customer. “The bit that’s currently the pain is the customer having to fish out their card and look for the number on the back to complete a payment, and these services avoid the need for that.”

From Google to expand Android Pay digital wallet to UK – BBC News

My point, as I said in that BBC news report, is that that apps deliver a better and more personalised service to the customer and allow the service provider to deliver a better customer experience around their purchase. What’s more, some of those customers won’t even download apps for casual purchases, they’ll just use bots sitting behind WhatsApp or Facebook Messenger whatever else it is that the kids of today are using. Imagine going to the car park at Woking station and instead of running RingGo just using Messenger are to send a message to RingGo instead. The grammar of a car park is pretty limited so is not that hard to construct a bot to manage the interaction. You don’t need Alpha Go to recognise an end time or “day” or “week” or whatever.

Mobile payments are going to be huge. Don’t visualise the commerce of the future as the half-baked agglomeration of cut-down web interfaces that you have on your phone right now, but the constellation of interacting apps on the infrastructure of the future.

Operators and mobile payments, the one millionth blog post

Greyscale backing image

There was an interesting article in the August edition of E-Finance & Payments Law & Policy from Carlo de Meijer and Jonathan Bye at RBS. It looked at the possibilities for different players in the mobile wallet world, exploring the potential for retailers, banks and handset manufacturers. I couldn’t help but notice that it doesn’t mention mobile operators. Mobile operators, by and large, are finding mobile payments tough.

Norwegian mobile payments service Valyou has been shut down, with owners Telenor, DNB and SpareBank 1 blaming a lack of NFC-enabled payment terminals and support from their fellow banks and telcos for their project’s failure.

[From Finextra: Finextra news: Norwegian mobile payments service Valyou shuts down]

Then I read John Stewart’s article “Dropped Call” in the October Digital Transactions magazine. He writes that many people think that the balance of power in mobile payments has already shifted away from the operators. They still have some power (he uses the example of Verizon Wireless holding out on Samsung Pay) but it is really just negotiating power. He also quotes Juniper Research saying that it is “rather sad if the operator role is to be defined as an inhibiting factor on service providers rather than an enabler”. Incidentally, they also note that “the minute the banks got the opportunity to pursue a model cut out the operators, which was what host card emulation offered, they took that chance”.

So that’s it for mobile operators then? Well, no. At least, not necessarily. As that Digital Transactions piece goes on to say, the operators might not be done in payments after all. There may be a role for them in critical businesses such as transaction security and user authentication (my emphasis). And some observers argue they could expand their stake in carrier billing as well, so they still have opportunities to do something in the mobile transactions world.

Of these there opportunities, I would say that if you can authenticate the device and authenticate consumer then you can help everyone else in the value chain to deliver a more secure transaction infrastructure, and that has some value. Now, I rather agree with this line of thinking, and I’ve made similar points before.

The key question is: will the banks and the mobile operators and the handset manufacturers and the platform providers the government be able to work together to deliver a mobile ID infrastructure just as they did not work together to deliver a mobile payments infrastructure?

[From Mobile payment is fun, but mobile ID might be indispensable | Consult Hyperion]

Maybe I was being a little unkind to the banks and the operators. It could be that in the case of identity, the dynamics will be different and the banks and the operators will find more common ground, where the operators provide the identity infrastructure (i.e., the digital identities and at least one of the virtual identities bound to them, namely the operator identity) and the banks provide the identities (i.e., the binding between the digital identities and mundane identities). Back in 2012, commenting on the GSMA Operator Connect proposal, I said that:

I don’t understand why MNOs don’t provide this service already

[From Mobile identity on the move | Consult Hyperion]

The reason I said that was because in the preceding couple of years, Consult Hyperion had been commissioned, more than once, to look at the potential for mobile operators in the identification and authentication space and we had been involved in a number of discussions on the topic, so I’d already formed the opinion that mobile ID would make sense. In fact, back in 2006, commenting on the Norwegian BankID scheme, I observed that mobile identity was more of an long term play than mobile payments (because I thought there would be more competitors in the mobile payment space), and went on to note “I said a long time ago that ‘SimID’ might be more profitable than Simpay (*)”.

Well, I don’t want to sound like a broken record but nine years on this is what I’ll be talking about again at the GSMA’s informal workshop on Financial Services in London on Thursday 26th November. Look forward to seeing you there!

(* Note to younger readers: Simpay was an attempt by mobile operators to build their own pan-European low-value retail payment scheme.)

Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.