This sounds like a case of stating the blindingly obvious.
In a recent article, Simon Buckingham made the point that mobile operators will always have aconflict of interests when billing users for third party content services. Operators have their own plans for both content services, and for billing and promotion of their core services and hence third parties will always come way down the pecking order when it comes to getting them hooked up. And even further down the pecking order if any new development is required for the third party’s service.
What’s new here? Right back to the introduction of reverse-billed SMS carriers have touted this feature for carrier-based billing for third parties. They used it for their own content-based services such as ring tone downloads, Java games and the like. And for low value content charging it worked quite well. I say quite, for there were always the odd problems with lost SMS messages and rather flaky delivery confirmations. It was also limited to single networks (i.e. there was no consistent cross-network premium SMS charging).
But the main problem was that SMS was never built as a charging mechanism, and one of the consequences was that the overhead to the mobile network was such that the true cost per transaction remained high. The other was that the price points were very limited and entirely dictated by the network operators, there was no scheme for variable price points dictated by the content vendor (i.e. the third party that was trying to build a business). Not that this stopped the network operators claiming they had invented mobile payments systems and attempting to exploit them with third parties.
We realised some time ago that, if the mobile operators were actually to have a play in the payments arena, things would need to change a lot. After all nobody was going to buy a fridge using reverse SMS to charge it to their mobile bill. People were used to using their credit cards to pay for tangible goods in shops and online, and the same model was most likely going to apply when using a mobile. But entering credit card details including billing name and address was never going to catch on when phones were still limited to small screens and 12 button keypads.
One of the thoughts was for a “mobile wallet”, a repository for all the information needed to make a purchase that was held in the network and invoked as you got to the “pay now” screen in a transaction. Conceptually an attractive idea, but one that had to be paid for somehow, and all the parties involved (buyer, seller, credit card company) were none too keen on paying more or losing margin. And yet again there was the likelihood that any solution would be network dependent with specific APIs (such as how the mobile wallet was invoked at the right point).
In the end it was never implemented, at least not by the operators. After all, what are PayPal or Google Checkout if not common payment methods used across multiple vendors, or indeed the Amazon APIs which happily sit in front of multiple shops and provide all the payment mechanisms needed? And the Apple iTunes app store just goes to show how slick content purchase and billing can be if you put a mind to it. Somehow I don’t think Mr Jobs considered for one minute using the mobile operators for content billing.