This post originated from an RSS feed registered with Java Buzz by Russell Beattie. Original Post: mGuru and Billing as The Solution to the Mobile Payments Feed Title: Russell Beattie Notebook Feed URL: http://www.russellbeattie.com/notebook/rss.jsp?q=java,code,mobile Feed Description: My online notebook with thoughts, comments, links and more. Latest Java Buzz Posts Latest Java Buzz Posts by Russell Beattie Latest Posts From Russell Beattie Notebook

This name is similar to the MobKnowledge domain I have, but a little cooler and a lot shorter, which is great for mobile phones. I'm still a big believer in the idea that mobile tech support is going to be in hot demand sooner than later, so this is a nice domain to have.

Anyways, I soon tried to go back to bed and get some sleep and I was going over the idea once again in my head. mGuru is nice and short which means it'll be more useful on mobiles. I started thinking about how I could use WURFL or DELI to detect which phone and customize a FAQ and Knowledge Base based on the phone's HTTP header. Then I started thinking about ways to charge for some content. Say you didn't find the information about the phone you were looking for, wouldn't it be cool to fill out a short form with your question, pay 99 cents and get a response within a few hours via SMS? Great, but how would I charge money for the service.

Well, right now there's not a lot of ways to get money out of mobile subscribers. You can make i-Mode like deals with the carriers, pray that some day MobiPay or SimPay actually take hold enough. Or if you're in countries that support it, you could go through an SMS aggregator and charge a premium SMS (but that would entail the user actively sending an SMS, and you've got them using their WAP/WAP2 browser at the moment). Then I started thinking about PayPal's new web services, which don't do much, but could possibly be used for something like this in the future.

And then it dawned on me. Why don't I just bill the user via email using something like PayPal? Think about it, the user enters their email and phone number on their phone, promises to pay the 99 cents when they get to a real computer and that's it. Done. No middle man, no carriers, no aggregators, no e-wallets, nothing. Just an old fashioned billing system.

Now of course, there will be lots of people who will never pay. Fine. Factor that into your business plan. But those people will continue to be molested by your automatic bill collecting email and SMS bots until they do and they don't get to use the service again if they've got, say $5 built up in un-paid charges. If they lie about their email or SMS, then they don't actually receive the answer (which by the way, could be longer than a normal SMS by sending a WAP Push or MMS message).

The idea is sort of the equivalent of ShareWare for (mobile) web services. The person who is using the service promises to pay later. Some will gladly pony up for the convenience, others will try to ditch the cost because they're like that. ShareWare built companies like McAffee, though, so I think it's a reasonable chance to take that people out there are good. You can even build up a credit system for those users who reliably pay their bills (just like in any other system).

There's lots of issues involved, I'm sure. But I honestly think this may be a real answer to the dilema of mobile payments: Bill My Email. Quick, easy and simple.

-Russ