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:
- 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.
- 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.
- 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.
Things that would make the Android Market in-app billing API nicer:
- 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.)
- An online (non-cached) mode, letting the app developer require Internet connectivity to use a feature.
- 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.
- 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.
- 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.