“Oh no!” (I can hear you say) “Not another blog about mobile payments…” Well, yes… and no.
I’m probably as fed up as you are with a lot of the stuff that gets written about “mobile payments” – almost as fed up as I am with the nonsense that people write about “mobile wallets”, but that’s a whole different discussion.
Why am I fed up? Well, basically because many of the blog posts and articles and much of the commentary around mobile payments cast too wide a net and addresses products, solutions or developments that are way wide of the mark when compared against a proper expression of a mobile payment implementation. All of this noise helps to perpetuate the idea that anything which involves:
- a mobile phone, and
- a payment of some sort
automatically qualifies as a “mobile payment”.
So, if I take out my Samsung Galaxy S4 and use the Chrome browser to call up the Tesco Dotcom site, place an order for groceries to be delivered over the weekend and then pay for the goods by entering my credit card details, then that’s a mobile payment, right? Or if my friendly neighbourhood plumber fixes that annoying leak under the sink and he accepts my credit card payment (well, it was an emergency!) by using his iPhone connected to an iZettle card reader, I’ve just made a mobile payment, haven’t I?
Compare that to walking into your nearest Starbucks with your Starbucks Rewards app open on your iPhone and presenting the “Pay” barcode to the scanner at the till to buy a caramel macchiato and a chocolate muffin – see the difference? It’s not the best example of a mobile payment by a long way, but at least it’s heading in the right direction insofar as you haven’t had to supply any payment credentials at the point of interaction to effect the payment (as in the Tesco example above) and you haven’t had to provide your plastic card to complete the transaction (as in the payment to the emergency plumber). Instead, information related to a payment card – in this case, the Starbucks Rewards card linked to a pre-paid account has been transferred from your mobile phone to the point of sale terminal, and all you had to do was wave your iPhone screen in front of the scanner.
If you want to get technical about it, you had to open your iPhone, which requires a screen swipe and (hopefully) a passcode; then you had to look for and open the Starbucks app; then you had to click on the “Pay” button and then orient the iPhone screen in such a way that the barcode could be read by the awkwardly positioned laser scanner… But it was easy, wasn’t it? And you got a star for making the purchase with your Starbucks Rewards card (in your iPhone app). So maybe it wasn’t that easy and it could have been better designed to ensure a smoother, more convenient customer experience, but it’s still more like a “real” mobile payment than the other examples above, despite its sub-optimal implementation.
So, in my view, there are true mobile payment solutions and there are other implementations which are “mobile payments” in name only. But what makes a good mobile payment product, as far as I’m concerned? Well, there are a number of factors at play in building a fit for purpose solution in the mobile payments space, including security, functionality and ubiquity of acceptance, but most of them revolve around the customer and the customer’s experience of using the mobile payment solution. I talk about this aspect of mobile payments and what customers are looking for in a mobile payment product in my recent white paper on mobile payments as well as discussing what makes a mobile payment a mobile payment. Take a look at it: it might help you appreciate why I get fed up with some of the stuff that I read about “mobile payments”.
What do you think? Post a reply below, contact me by email at email@example.com.