The clip starting at 10:00 in this video (courtesy Ketai) starkly represents why many mPayment schemes will not succeed - simply because you can do something doesn't mean you will or should do it.
mPayments will certainly work, if they offer a significant benefit to the user over all alternatives, and are sufficiently easy and obvious that the user will think of attempting them. In many implementations I have seen, this is sadly not the case. Cash or cards are just easy natural payment systems, so the phone should only be brought in where these alone are not possible.
To succeed, the payment system needs to take the minimum of clicks and be resilient to error. It needs to interface seamlessly with the vendor/machine, just like a credit card terminal does in a shop - and just like dropping a coin in a slot does. If either of those is a viable alternative and the ease of use does not match them, you're toast.
This suggests that the most fruitful targets are payments for less tangible things you can predict you need whilst on the move - like tickets - where there is huge benefit in the convenience of eg. not queuing behind ten slow people for a machine which may be out of change when you reach it, whilst your train is pulling out of the station. You could even buy the ticket with your phone after boarding the train, an option which has disappeared on many UK trains in recent years.
Having selected a 'mobile friendly' payment, you need to work out what the best platform is for taking it - which involves weighing up a number of factors:
- For a small rapid payment with limited options that can absorb a 30-60% margin, Premium SMS (PSMS) is king
- The response can even include simple barcodes, though not the complex ones likely to become standard in most applications;
- For anything more complex, margin sensitive or larger than a few pounds/euros/dollars PSMS cannot be used.
- The mobile web implemented well will offer rapid access for a user
- It can have big problems for multistep payments when the user is on the move (flaky connections, no on-client validation etc)
- There are also security concerns with some handsets/networks;
- For regular payments a thick client offers big advantages if it is written to work for the whole mass market
- Greater ease of use eg. with on-client validation, interactive help etc;
- More resilience to poor connections;
- Lower data costs.
Even with a good target service, success is not guaranteed - the process still needs to be smooth and just work, something sadly lacking for so many reasons in today's mobile experience. To quote Andrew Orlowski on the Register:
"Today's mobile hypesters who confidently predict the web going mobile, forgot that the web competes with local knowledge. It's almost always quicker (and more fun) to be prepared in advance, or ask someone, once mobile. You can ask someone next to you, or you can call a friend: either is quicker than tapping away on a phone. Mobile surfing was crap when it was WAP, crap now it's an XHTML browser, and will be crap when it's an AJAX Widget."
mPayments are not for everything. Before embarking on a trial just place yourself in the shoes of a user and ask - why does this make my life easier than the alternatives at my disposal? Only continue if you can answer that question honestly. We're currently getting great feedback from rail ticketing and parking trials and we're pursuing a number of other clear business cases with our partners - but we're steering clear of Coke vending machine purchases as coins look set to have some life in them yet!
