NFC vs. Not-NFC, or “Why Put Card Data on the Phone?” A look at Mocapay

by Carol Coye Benson on February 23, 2010

in Carol Coye Benson, Credit Cards, Mobile Banking & Payments, P2P

Post image for NFC vs. Not-NFC, or “Why Put Card Data on the Phone?” A look at Mocapay

When it comes to mobile payments in the U.S. market, there’s a lot of talk and action around P2P and remote purchasing (bill to carrier models, etc.).  But the biggest potential is our huge POS (point of sale) market.  This market today is arguably the best-served payments market in the world, with extensive merchant terminalization and multiple cards in the hands of all banked and many non-banked consumers.

The assumed path forward for mobile at the POS has been NFC (near field communication) technology.  The technology is reasonably stable and has been extensively trialed around the world, with encouraging consumer reactions.  Despite this, there has been little in the way of commercial launches – and none in the U.S. market.  That may be about to change – rumors are rife in the industry that major mobile NFC/POS announcements are imminent  – possibly through a consortium of carriers working with a single or a group of card issuers.

If there is an NFC introduction, the players will have to tackle the “usual suspects” – the reasons that NFC has been stalled, to date, in the U.S. and in many markets around the world (see “Common Wisdom” inset below).

Common Wisdom: Why NFC at the POS Has Stalled

  • An economic stand-off between card issuers and carriers over fees paid by issuers to carriers to enable secure storage of card data on phones: the fees could be one-time, recurring, or even include a portion of issuer’s card interchange.  Carriers understandably want value for access to the phone’s secure storage capabilities; issuers understandably are reluctant to cough up incremental and ongoing fees for a technology that is most probably replacing, not adding to, existing card swipe transaction volume
  • The cost of adding NFC chips to phones, which currently don’t have them
  • The cost of upgrading merchant terminals to support NFC.  (Terminals in the U.S. which currently support contactless cards can already support NFC, but this is mostly concentrated in the quick-serve markets such as convenience stores, drug stores, and fast food outlets.)
  • A concern that consumers may not really want to use their phone to pay: the lackluster adoption of contactless cards is seen by some as indicative of this; others feel the comparison is irrelevant and cite the growing importance of phones in daily life and transactions for the consumer
  • An overall feeling of “a technology that’s solving a problem that doesn’t exist” – a belief that consumers love cards and think they are convenient to use


I’ve been intrigued, recently, with a number of alternative approaches to mobile POS that are becoming increasingly visible.

Some of the alternatives are work-arounds to the carrier control of secure data on the phone – these approaches include the use of SD cards, USB sticks, and stickers (especially, “super-stickers” with secure and NFC chip outside the phone – and therefore outside of carrier control).

I’ve also been thinking a lot about what’s going on with payments in eCommerce, and how it may apply at the point of sale.  All merchants – eCommerce and POS merchants alike – have been struggling with the enormous costs and difficulties of PCI compliance in recent years.  In a nutshell, the problem is securing card data.  eCommerce payments providers, taking advantage of the remote environment, have been increasingly focusing on tokenization – a scheme which keeps card data away from a merchant entirely.

Why can’t this approach work for mobile payments?  Instead of going through huge contortions to store data securely on the phone – and possibly paying through the nose for it – why not simply avoid putting the card data on the phone?


One company that is taking this approach is Denver-based Mocapay.  I spoke recently with CEO Kevin Grieve and VP Product Doug Hurst.  Mocapay has a tokenization scheme that keeps the card data away from the merchant. Currently, they are using this for gift cards.  But the approach could easily be applied to open-loop payment schemes as well.  Here’s how it works:mocapay image

  1. A consumer registers a card with Mocapay online or with their mobile phone
  2. The merchant signs up for Mocapay and installs software for its POS system. (According to Mocapay, the software, which is delivered on a software-as-a-service  model, is simple and easy for merchants to install.)
  3. The consumer, when ready to pay, opens an application on the phone, chooses the card, and pushes a button “get payment code”.  (If the consumer has a simple phone, they do this with an SMS message.)
  4. The Mocapay server immediately returns a code to the consumer’s phone.  The code is good for a limited amount of time (e.g. 20 minutes).  The code is six digits, in two blocks of three easy-to-remember numbers. (The scheme also supports 2d barcodes as an alternative, but Kevin seems to think this is an unnecessary complication – the short, grouped number code works so well you don’t need new barcode-reading hardware.)
  5. The consumer then reads the code to the cashier, or shows the cashier the phone.  (Mocapay recounts that cashiers are often picking up the code from the phone laying on the counter – reading it upside down!)
  6. The cashier enters the code, which is transmitted to Mocapay, which passes the transaction – now authenticated – into the payment processing stream, for authorization and clearing like any other payment card.

What works:  This is an incredibly simple scheme.  No one has to buy any new hardware (works with any phone, any terminal).  Card data is secure, as the merchant never sees it.

What will be debated:  Mocapay claims that the end-to-end card payment time (counting getting your card out, and swiping it) is tied with their approach in a no-signature environment, and that their approach is faster if signatures are required.  Common sense would tend to question this (cards are really fast) – but it is true that many people have their phones easily at hand, and their cards tucked away in wallets and purses.

Where this may go: the gift card scenario is intriguing, but the real payoff here is the potential to expand this to open loop cards and/or ACH payments.  Mocapay isn’t there yet, although they are clearly thinking about it.  The big question for open-loop cards isn’t whether or not it would work (it seems pretty clear that it could), but whether or not the card networks will support the technology – and grant the all-important “card present” status: if not, increased interchange rates would kill the approach with current merchants. Visa and MasterCard are pretty far down the road with NFC – it’s hard to read how they might evaluate this opportunity.  It is also interesting to note that the PIN debit networks have been increasingly flexible with rules lately – and this may be just the opportunity for them. (It is also useful to remember that a refusal by the card networks to grant “card present” status  was, famously, one of the problems the late Pay By Touch encountered.  Some speculated that the underlying reason that the card networks withheld the status was not a concern about security, but rather one about issuer and network branding.  The branding issue goes away in the Mocapay scenario – at least for smart phone and WAP users.)

Another consideration is that this scheme is easily extended to an eCommerce or unattended POS environment.  For eCommerce in the U.S. market, it would be interesting if this could be used to create “card-present” transactions – making use of the inherent authentication value of the phone.  Far simpler, it seems to me, than pushing the 3D Secure rock up the hill.  And it is a very neat trick to have the same system work in the various environments, rather than requiring consumers to keep track of different protocols for different places.  Again, this is, of course, nothing but idle speculation without the blessing of the networks.

Mocapay announced today that they have been issued a U.S. patent on the process.  If I were a card issuer, I’d be looking at this approach closely – and leaning on my card networks to do the same.   Remember – the first principle of process improvement is to eliminate tasks, rather than automate them.  Eliminating the storage of card data on hundreds of millions of hard-to-control devices seems like a concept worth considering.

3 Responses to “NFC vs. Not-NFC, or “Why Put Card Data on the Phone?” A look at Mocapay”

  1. Jill Autry says:

    Interesting approach, but still seems to underestimate merchant incentives and willingness to install software on their POS and pay Mocapay to support this. Everyone says their software is simple and easy, but it still takes time and resources for merchants to integrate any new software. This is especially true for larger retailers, who typically have highly – customized POS software and need remote management and reporting. You need a really strong business case before doing this and it has to be more compelling than anything else you might be doing with your POS. Still feels like the same chicken- egg problem that you have with NFC…

  2. Jason Shin says:

    Instead of using strictly required security, Mocapay took a brillant way. However there is just one thing I am concerning about is somewhere in inconvenience of verbal conveyance of the card number or of obtaining a short message in front of the counter of retailers. In addition, the process getting a payment code should be secured, it means it requires any kinds of user-authentication for the mobile app. I am not quite sure whether or not customers could treat it as a simple process as compared to swiping or tapping with a card. Let’s think about this more for Mocapay’s brighter future.

  3. Amit Sharma says:

    I believe mocaPay should continue with 2d barcodes to make it better secured. Instead of generating just a code which can be accessed for a particular duration which may lead to fraudalent trasactions, its advisable to go for 2d barcodes which can be read by an hardware for authentication at merchant customer. This will achieve a higher level of security.

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics