Mobile Commerce Transactions, NFC and mTicketing

juniper.gifJuniper has new research that says that Mobile Commerce Transactions will Approach 200bn By 2019. If you want to be part of this, Juniper say that NFC and mTicketing are likely to be the top growth areas.

However, if you get involved with NFC and ticketing then make sure it’s secure. As Trend Micro recently demonstrated, poorly designed/implemented systems can easily be hacked. There’s probably a great business waiting to happen (or already happened) for the right company that can white-label secure NFC/mTicketing solutions.

Apple Pay Limitations

apple.gifThere’s an interesting article on USA Today Money quoting a UBS report explaining problems with Apple Pay that will limit its dominance…
  • Onerous fees charged by Apple
  • Inferior technology
  • Little incentive for merchants to adopt Apple Pay-compatible devices

More reasons then, why Apple should open up NFC before interested parties develop alternative solutions.

Looking wider, this provides learnings for any new venture. Are the fees you expect to charge reasonable in the current (and future market), can people easily circumvent your solution using other technologies and are you expecting too much of third parties to change/update their systems in order to be part of your solution? I suppose it’s really about having an old fashioned business model which is one of the stages of my primer.

The Future of Apple Pay and NFC

apple.gifI have been analysing Apple Pay to determine if it’s likely to accelerate mobile payment in general and the use of NFC. FirstPartner have an explanation how Apple Pay Works and Penrillian explain how the market isn’t open yet.

The initial implementation is US only, supports only 1.5% of US merchants, relies on the unpopular Apple Passbook and will only work on newer devices containing NFC. Hence, in the short term it won’t be used by many people. More importantly, the implementation is currently closed in that it only allows NFC payments via Apple. It isn’t possible for third parties to use NFC to build more universal, ubiquitous payment solutions. While the essential building blocks for ‘universal’ NFC-based systems across Android/iOS will soon be in place, such systems are blocked by Apple’s strategies.

NFC isn’t just about payment. It can be used in security, authentication, stock control and a myriad of contextual triggering apps, many in the growing realm of the Internet of Things (IoT). All these possibilities of using NFC are closed on iOS for now. However, I suspect that as with apps, when initially Apple said there would be no native apps and only web apps, they will have to open things up. A universal payments system is too compelling and it’s incomprehensible that Apple will stay closed in this area for so little apparent gain. The Internet of Things needs NFC as well as Bluetooth LE (iBeacons). I believe Apple will see themselves under increasing pressure from many directions to open up the NFC APIs.

Update: Adam Cohen-Rose has pointed me to an interesting article by Clover that describes how the network-side token system was proposed/implemented by the payment networks (Mastercard, Visa). There’s no reason why this couldn’t be, and probably will be, implemented on say Android. This suggests a ‘universal’ system might be viable provided it uses a similar network-side token system.

Update: In an email to Cult of Mac, an Apple spokeswoman confirmed that NFC chip on the iPhone 6 and 6 Plus is only for use with Apple Pay. Like Touch ID on the iPhone 5s, Apple is keeping its NFC restricted from developers, at least for its first year.

Update: Mark Ranta asks Where’s the Beef? and hopes Apple Pay is just the first (baby) step.

Update: Teardown shows NFC chip is from NXP.

Update: Why Apple Pay Won’t Work.  

Mobile Path to Purchase

thinkinsights.gifIf you have a physical product to sell and you want to sell it via mobile, what should you do? Should you use conventional AdWords advertising, create a mobile accessible web store or an app? In what ways do consumers search/research products and in what ways are they completing the purchase?

 googlepathtopurchase.png

Google Think Insights has some new free research on the Mobile Path to Purchase. It shows that traditional search (48%) is the primary method of finding products but branded web sites (33%) and branded apps (26%) are also used. The key to purchasing conversion is proximity to store. Consumers tend to purchase in store (82%) or online (45%) with only 17% purchasing directly on the phone.

This isn’t good news for those currently working in the mobile payments space. One thing the report doesn’t cover is why only 17% purchase on the phone. Is it ease of use, security concerns or something else that is holding back consumers?

The Impact of Price on Revenue

distmo.gifAt some stage most developers offering paid apps ask themselves if they might make more money by lowering (or sometimes increasing) the price of their app. Distimo has done some interesting analysis on the impact of price drops on the iPad and iPhone app stores.

The conclusion is that price drops positively affect revenue…

 distimopricedrops.png

My own not-so-scientific experience of this, over the last decade and a half, across several platforms, is that lowering the price from a ‘high end’ price to an ‘below average’ price has always increased revenue. However, you have to factor in the cost of all those extra users. It’s less about server side costs and more about technical support. Supporting very large numbers of users can be tricky and time consuming.

Mobile Payments, Security and Convenience

surveymonkeyblog.pngIf you are thinking of selling physical goods from within an app then you should take a look at SurveyMonkey’s latest survey of over 600 mobile phone users.

The main conclusions are that mobile still suffers from end-user security concerns, Paypal is the most well-known payment solution and people re using mobile payments mainly for convenience.

I think that, as was the case with the web, people will eventually come to trust paying by mobile. The convenience thing is interesting because many solutions currently aren’t that easy to use. Companies that are well placed to introduce simplifications and improve on the user experience will probably be the ones that have the initial successes.

How Many Apps?

questionmark.pngThere’s sometimes a question as to how many apps an organisation/company should produce. Should you bundle all required functionality into one app or produce separate apps?

The overriding consideration is obviously cost. It costs a lot more to produce, test, support and distribute multiple apps rather than have everything on one app. So what considerations might make the added cost worth it? Here are some scenarios I have come across that have resulted in multiple apps…

  • Where having multiple apps will lead to more overall engagement. For example, an app used primarily for marketing might have functionality spread over several apps, over time, so as to spread and increase engagement over time.
  • When it’s known all the functionality won’t be ready all at once and it’s technically difficult to upgrade older functionality if it were all in one upgraded app.
  • When the functionality is totally separate and we don’t want users to know or care about functionality they won’t even use. e.g. Partitioning apps by enterprise job function (or this can also be done with one app by only showing functionality applicable to the user).
  • When the user experience for given functionality needs to be very different and placing all in one app would produce a confused app and confused users.
  • When functionality is monetised differently (e.g. Free vs Paid). A free app is sometimes used as a lead-in for a paid app even though the functionality of the two are different, yet related. e.g. A PDF reader app might be a free app that leads to a paid app that scans things and produces PDFs.
  • When it’s easier to monetise incrementally per app rather than multiple in-app payment. For example, content is often less visible embedded with other content within an app but it might be more visible if presented as an app in its own right. e.g. People might search for book topics, not a book reader.

Mobile and 2 Factor Authentication

paypal2factorauth.pngIf you are offering an app that needs stronger login methods then you should take a look at 2 factor authentication. In summary, you force users to login using their usual username/password and additionally require another id, typically a PIN that’s only valid for a short time. This is the same as the smart cards/tokens companies provide to employees to login via VPN. In mobile solutions, this usually translates to sending the PIN to the user via SMS when they attempt to login.

First some advice as a user rather than a developer: It’s little known for some reason, that both Google and PayPal allow you to use these authentication schemes. Google has an Authenticator app that you run on your Android, iOS or BlackBerry phone to generate the PIN while PayPal sends its PIN via SMS. Paypal also have a credit card size PIN generator that some users (not sure which exactly) can purchase. If you don’t already use these yourself then I recommend you do as they make your accounts much more secure.

Anyway, if you want to use such a scheme for your app you would do well to look at Paypal’s implementation as it has a few problems you can avoid. The first is that if you login via the mobile web site, rather than the desktop site, it doesn’t send a PIN. Very annoying. The lesson here is to make sure you cover all the ways the user is likely to login. The second problem with the PayPal implementation is that you don’t actually need the PIN and can instead enter extra personal information to gain access thus defeating many of the gains of two factor authentication. Lesson two is to think about how the user gains access when, under rare circumstances, they might not have access to the PIN. It shouldn’t be too easy to gain access and you should perhaps use a further second factor method rather than relying wholly on the first factor.