Why I'm not using Android Market in-app billing

From a developer's standpoint, Android Market's in-app billing service is not that fun to use. It really doesn't give me any feeling of a well-designed API, like I've gotten from Twilio, and Stripe more recently. The whole in-app billing implementation pushes a lot more responsibility onto the app developer for what appears to be little gain.

The one benefit that I can see is that people will get to use Google Checkout without the extra login step. Android Market managed purchases are essentially useless in their current form, since the app developer has to store redundant info anyway in the case of doing content distribution.

Here are the reasons why it does make sense to have the app developer implement most of the in-app billing:

1. Security. One recurring theme in the in-app billing documentation is that for security, the developer should do things like implement a remote server, and rewrite the sample code so it's tougher to reverse-engineer.
2. Managed purchases. The way Android Market in-app billing works with managed purchases, is that it keeps track of a boolean yes/no whether you've bought a given product. However there is no mechanism to restrict content distribution from a remote server, so in that case it makes sense to have the app developer implement that piece.
3. Identifying the user. It's difficult to know anything about the user of an Android device, or any identifying features of the device itself, which is why in-app billing requires a Google account, via Android Market. If you want to do anything more sophisticated than just finding out if the user has paid, such as anything surrounding content distribution, then it's up to you as the app developer to come up with some identity management scheme. I.e., have a separate login, since Android Market isn't about to tell you the user's email.

As you can see, it all ties back in with security. It's great that the documentation suggests several best practices for billing, but Google didn't really go far enough this time to make things easy on the developer.

Things that would make the Android Market in-app billing API nicer:

1. A service to deliver content. (Maybe they don't have the infrastructure or business strategy for this service right now, in the context of Android Market at least.)
2. An online (non-cached) mode, letting the app developer require Internet connectivity to use a feature.
3. A way to create and distribute encryption keys. I'd love for Android Market to have a way to make callbacks to our web servers and help distribute encryption keys or other sensitive info, without unnaturally routing that info through the client app and then to our remote server.
4. Giving us unique identifiers for users. This would save a lot of trouble and help with many apps that wouldn't normally require accounts, but only need some identifier to make sure the user has paid.
5. Allowing more flexible payment models, like variable prices (good for donations) and managing numeric quantities of items (with an optional max limit) instead of just a boolean yes/no whether the user has purchased it before.

I'm sure Android Market in-app billing will evolve more in the future, but it's a shame that the initial release is so feature-constrained and not-nice for developers. It's because of the shortcomings described in this post--plus the fact that Android Market payments of course requires Android Market and therefore doesn't reach nearly the entire ecosystem of Android devices--that I may go with Paypal Mobile Payments as the main payment method for my next project.