Android in-app billing docs... | Hacker News Reader

Android in-app billing docs...

developer.android.com

33 pointsrst14 comments

Does anyone know what the rules are with Android and iPhone about selling physical goods through an app? I want to sell seeds through the SproutRobot app.

Near as I can tell you're allowed to have users punch their credit card into your app and bill them using your own gateway, on both iOS and Android. But the recent events with Sony make me unsure. And Google seems like they'd be more liberal about in-app payments, but these docs say they are for "virtual" goods.

Apple will not allow you, and I've heard as such. They have specific examples that can be Venn Diagrammed to your app being giving a rejection.

From the iPhone App Store Guidelines

11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected

11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected

20.4 Apps that allow a user to directly purchase a lottery or raffle ticket in the app will be rejected

21.2 The collection of donations must be done via a web site in Safari or an SMS

http://stadium.weblogsinc.com/engadget/files/app-store-guide...

Selling physical goods, like seeds, is fine.

Per 11.3, you cannot use Apple's IAP system to sell physical goods. You can use your own.

Thanks. I stand corrected. Now I need to get some time to build the app for my friend that I told him would be rejected because of my incorrect line of reasoning.

Yes, it's fine to sell physical goods through an app.

There's certainly precedent for it being allowed with things like the Zappos app (http://www.zappos.com/iphone-app). I don't have an iPhone to try it with, but from the description it certainly sounds like you can buy shoes and such directly from the app.

There's also the Amazon mobile app, the B&N Bookstore app, the NewEgg Mobile app, even Sears2go.

Its definitely a very very grey area

From the current docs for Google in app purchase: http://developer.android.com/guide/market/billing/billing_ov... "You can use in-app billing to sell only digital content. You cannot use in-app billing to sell physical goods, personal services, or anything that requires physical delivery."

I'd check the terms and conditions of the stores about using other payment gateways as well

http://www.android.com/us/developer-distribution-agreement.h...

Payment Processor(s): Any party authorized by Google to provide payment processing services that enable Developers with optional Payment Accounts to charge Device users for Products distributed via the Market.

However the advantage of the Android platform is that the market is not the only app store available and also app stores are not the only means of distribution

You can't use Google's new in-app billing service. But both Google and Apple absolutely do allow you to sell physical goods through an app using your own billing process. Witness the number of shopping apps, including the Amazon app, Sears2go, etc. that allow you to purchase goods on your phone/tablet.

I agree there are apps that currently have integrations with differing payment processors, (Amazon, Paypal, existing service logins, traditional clearing houses) however if you are not launching off to a browser, you should definitely be aware of what the terms and conditions you have agreed to state

Important: Although the sample application is a working example of how you can implement in-app billing, we strongly recommend that you modify and obfuscate the sample code before you use it in a production application.

uhm? is the security left to code on the device alone?

This is probably intended as an (inevitably partial) defense against people copying application .APK files and their associated data between devices, or altering the .APKs to be able to get stuff without paying for it. Here's a discussion of the issue in the context of their licensing verification library:

http://android-developers.blogspot.com/2010/09/securing-andr...

I'm not sure that precisely the same threat model applies, but they may be thinking "better safe than sorry" regardless.

haven't read that article yet, but my point is that if Google is acting as a payment gateway, they should probably provide some means to verify purchases with the server, not tell you to obfuscate your code to prevent people from reverse engineering the keys and algorithms.

That's how their licensing verification stuff works. The problem is that someone could copy your app's code (the .APK file) and alter it to not communicate with the server, or ignore its response. There's nothing the licensing code or library can do once it the attacker has gone in and disabled it; their main suggested defense, for now, is obfuscating the code so that alteration is hard to do.

You can not (as in, you're straight up not allowed) to sell physical goods via Apple's in-app purchase. It's only for digital goods. You can sell physical goods through other payment systems though, that are not Apple's in-app stuff.

Reply on news.ycombinator.com