Mobile payments made easy

This is just in: Google seems to be taking steps to allow operator billing. If that’s true it’s huge news.

Note from the outset that the article doesn’t say in so many words that operator billing is coming, although it certainly gives that impression, and plenty of publications translate it as such.

The basic idea of operator billing is very simple: if you want to buy an app, or access to online content, the price is automatically added to your operator bill (or, I assume, deducted from your pre-paid account).

Now I’m not a mobile billing specialist by any means, but I still want to give you an idea of what we’re talking about. If I make any technical mistakes, please correct them in the comments.

The billing process

Just yesterday I made my first Android Market purchase, and although the process was relatively smooth, I still had to fill in all my credit card stuff, make mistakes, being told off, etc. Besides, when I tried to do the same a few months ago, the Android Market rejected my credit card. Why? Probably because the Dutch market wasn’t active yet — but I thought of that only much later. At the moment I was pretty pissed.

Now with operator billing I wouldn’t have all this hassle. I’d just click on whatever I want to buy, give a one-time confirmation “Yes, I do want to spend € 2.39 on this” and be done. When my next operator bill comes around, the € 2.39 will be added to it.

In addition, operators can verify your identity through your SIM card, without you having to do anything. No more hassle with credit card numbers. (In fact, the only parties that have a lot to lose from operator billing are the credit card companies. Expect resistance from them; they’ll probably say it’s unsafe or something.)

Thus operator billing is by far the most user-friendly way of making mobile purchases. That’s what makes it so important. Besides, it also opens up the mobile marketplace to those that do not have a credit card.

A question of identity

However, Google’s rather vague announcement does leave some questions unanswered. No doubt that’s because Google is still figuring out how to answer those questions. But let’s review them anyway:

The last question is probably the most important one. If I want to make a purchase through operator billing, there are three parties involved: me, the selling party, and the operator. Somehow, the selling party has to connect to the operator to figure out exactly who I am, and to make a request to put € 2.39 on my bill for my purchase. In addition, the operator has to pay that money (maybe minus a fee) to the selling party.

The JIL 1.2 API gives us some clues as to how this system is going to work. This API, that will eventually be implemented in Vodafone 360 phones as well as, one hopes, many others, has two properties that are meant specifically for operator billing (p. 16):

Widget.Device.AccountInfo.phoneUserUniqueId
Widget.Device.AccountInfo.phoneOperatorName

Thus, when purchase times comes around, the store has some grip on your identity. It will have to send off a communication to the specified operator stating that user with unique ID X wants to make a € 2.39 purchase.

The operator will have to make some effort to verify this information; after all I might be able to hack a phone to send false unique IDs. Thus the operator will probably send me an SMS “Are you sure you want to purchase product X for € 2.39?“ Once I reply to that SMS the purchase is made and downloading can commence.

Still, I hope that the process will become even more user-friendly. The same JIL specification defines a way to send an SMS from a widget. Thus, if I want to purchase something the system could automatically generate an SMS for me and send it off to the operator. Thus the operator will be able to verify my intent by comparing my unique user ID with the SIM card through which the SMS was sent. If they match the purchase is made and downloading can commence.

That’s one step less, and thus more user-friendly. Hell, if it’s implemented correctly I don’t even have to switch to my SMS application. (The operator still has to tell the store “Purchase made, proceed with download.” But a proper system will not bother me with the details.)

Unfortunately the JIL 1.2 spec does not yet contain the methods that will be used for actual payments, nor the exact workflow. Besides, it’s unclear which operators Google is talking to right now. Probably US-based ones, and of those only Verizon is part of the JIL consortium. The others might use other APIs. (Come to think of it, so might Verizon. One never knows.)

Future expansion

Let’s close on a positive note and assume that a system roughly similar to what I describe above will actually be in place in two years or so. Apart from the increased user-friendliness of the purchasing process, what will it bring?

The basic answer is Long Tail. Increased user-friendliness and the scrapping of the requirement to own a credit card may entice more consumers to make a mobile purchase. That would be good.

The real benefit will lie with developers, though. In theory, the system could be set up so that individual developers who offer one or two apps for download on their own site can also use it.

Thus the requirement to offer your wares through one or more app stores might also be scrapped. That could be especially important to cross-platform apps such as W3C Widgets. Whichever phone with whichever operator ends up at the developer’s site, they can all make a purchase, provided they support widgets.

One more nail in the app stores’ coffin would be the opportunity to make in-app purchases; say some articles from a news site or a few new levels for your game. Operator billing is explicitly meant for such purchases, too. And if we can use operator billing in our apps, too, the app store infrastructure is basically not necessary any more.

Picture the following:

  1. I write a news reader app as a W3C Widget. Anyone can download it for free from my website.
  2. If you like my app you can share it with your friends. Just send over the widget via Bluetooth. No more complicated user-unfriendly Send-To-Friend systems necessary.
  3. But how do I make money? By selling access to the actual articles. Every article you want to read costs you, say € 0.02. Alternatively, you can buy a day of unlimited access for, I don’t know, € 0.99.
  4. All the billing is done in-app through the operator. My users never have to do anything beyond saying “Yes, I want to buy this article.”

Where’s the app store in this process? Nowhere. We don’t need it any more. Wouldn’t that be something?

(I should note that although sending widgets via Bluetooth is possible nowadays — I’ve done it — the process is not very user-friendly yet. But this functionality is definitely coming; it’s not a pipe dream.)

Waiting for Google

So I’m impatiently waiting for Google to announce more details. Exactly how will their system work? What does the user have to do? Which operators? Questions, questions.

Anyway, the future of mobile payments has come one step closer.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories:

Comments

Comments are closed.

1 Posted by Chen Ze on 27 July 2010 | Permalink

Not sure the situation oversea but in China here the operator billing is the most popular payment method for mobile users.

2 Posted by Alberto on 27 July 2010 | Permalink

I know Vodafone NL (I worked there until recently) has had an API for 3rd party billing in place for years now.

Any game/ringtone/content purchases you do on (what used to be) the Vodafone Live! portal make use of this interface. It's nothing new.

3 Posted by Maciej K. on 27 July 2010 | Permalink

Isn't it almost the same as Premium SMS service? It works for years for virtual goods payments here in Poland. The only issue is ~60% commision of operators !

4 Posted by Marcelo Emmerich on 27 July 2010 | Permalink

ppk, for me the key issue in mobile payment in terms of web technologies is security. How do you protect payed web content? Would like to know what you think about this.

Cheers,

Marcelo

5 Posted by Axel Berger on 28 July 2010 | Permalink

Marcelo, protection usually is nothing more or less than a huge pain in the proverbial for normal honest customers. For PPK's two-cent-article it is probably cheaper to get it from the source that to send and forward it through a mobile device. If so, that's the best protection possible.

6 Posted by Web Tasarim | John Alden on 28 July 2010 | Permalink

These are actually lovely news. Lately i've been seeing some changes on mobility from most of the companies out there. It'd be lovely to make payments from your phone :) Haha, as if Google hasn't put her hands in everywhere now :P

7 Posted by webton webdesign on 29 July 2010 | Permalink

Not sure the situation oversea but in China here the operator billing is the most popular payment method for mobile users.

8 Posted by Jannes on 30 July 2010 | Permalink

All in all, there are three obvious requirements needed for users, mirrored by three requirements for 'stores':
1) Authority of payment: the user is in control of all payments, i.e. the interface and process through which he/she confirms payment should be secure.
2) Privacy of transaction: a store should not be able to get the identity of the buyer, so the ID (or other implementation detail) should be dynamic from purchase to purchase.
3) Guarantee of product: after payment, the product must be transferred and must satisfy expectations.

For stores:
1) Authority of delivery
2) Privacy of transaction
3) Guarantee of payment

Obviously a third party is terrific for exchanging the product for the payment. The operator is the preferred third party, as it already holds the money and the trust of the buyer. So the product should be delivered to the operator, who will exchange them after dual confirmation. If the operator is trusted, privacy can also be maintained.

Sadly, whether or not products confirm to expectations is almost uncheckable and this scheme is only feasible if the product can be completely transferred to the operator (unlike most services). Luckily, operators are well positioned to represent users' interest.