Proxama Blog

NFC Payment Confirmed

Anyone in the business of developing mobile applications is only too aware of the problems caused by J2me fragmentation. The lack of consistency in how handset manufacturers implement J2me has spawned a whole support industry – companies like Mobile Distillery exist precisely to ease this pain.

Java and NFC

Where developing NFC applications is concerned, there are only two handsets commercially available. (We know that LG and Sagem have models close to launch but Nokia is the only company that has a production line going). So in this respect, developing NFC applications is a dream. We write once and it runs anywhere. It’s not completely without issue though - there are some missing elements in the NFC API that Java applications use (the JSR257 specification to be precise) that do have an impact on application development.

Want a quick example? Imagine you have your NFC phone and you’ve installed a wallet because you want to keep a number of cards on there – your debit card (which you set as your default payment card), Oyster and gym membership. You are in Prêt a manger, you take your phone out of your pocket and you tap to pay. The payment is made with your debit card – because that’s the default card – the wallet jumps into action and you get a pop-up screen confirming “payment successful”. If you have been in the queue for a few minutes and already have the wallet open – looking at your cards, checking balances or something – when you come to pay, your card will work fine and your account will be debited, but you won’t get the pop up confirmation. 

Blame it on the Push Registry

Why is this? It relates to a mechanism called the “push registry”. The push registry will launch an application – in this case it’s the wallet – according to specified criteria. This criteria could be an event such as an incoming SMS (from your bank, asking you to update an expired card), or use of a payment card (displaying the “payment confirmed” dialog). So, when the phone is idle, the wallet is launched when the card is used and you get the confirmation dialog.

You would have thought that the same would be true when the wallet is already open. Unfortunately not, and here’s why. If an application is already running, the push registry will ignore an event fitting the criteria, because the job is already done – in this case, the wallet is already open. Crucially, the push registry can only launch an application. So what point am I making? If JSR257 also contained an interface to communicate this information when an application is running, we could use it to display a “Payment Confirmed” dialog (whilst the wallet was open). But it doesn’t.

Applications in the Real World

I am not hugely worried about this. I have posted a question to the Nokia Forum and I’m sure it will be resolved. Nokia has already ironed out similar issues to do with JSR257 extensions. And in the meantime there are some work arounds (that have their own problems) but I think it makes an interesting point about platforms, software and applications. Despite best intentions and cross industry working groups, once the developer community get their hands on the specs and start to build applications for real people to use, in real life situations, we’ll always discover loopholes that need to be tightened up to deliver the best possible consumer experience.

Tagged with Mobile Mobile payments Near Field Communication PayPass Wallets

0 Comments. Posted by James 09 March 2009

---

Name:

Email:

Location:

URL:

Remember my personal information

Notify me of follow-up comments?