Limit iPhone in-app purchase by user's country

Question

Hello everyone.

I'm a product manager who works for a small internet company that is developing an iPhone application for a social network. We monetize by offering limited and premium memberships to users (premium members get additional features not available to limited members). For billing on the web, we use a 3rd-party payment gateway that is nearing retirement, and will be replaced by an in-house solution.

The business wants a global launch for our iPhone app using iTunes + in-app purchasing as a payment gateway. The problem with going global using this payment method is that for our web service membership level, available features, and subscription costs are defined by country. For example, in the US premium/limited memberships are available at 5 pricing tiers; in France premium/limited memberships are available at 5 different pricing tiers from the US; and in Chile the service is available for free and all features are available to users.

Is it possible then to have the server-side, based on the user's country of registration, control the level of access, features, and payment options for users on the iPhone? I'd also note that since iTunes Connect does not allow variable pricing by currency and country, each "region" would need 5 in app purchase options.

I argued for a US-only launch for iPhone using iTunes in app purchase until an in-house payment gateway is available. But you know...

Answer 1

"Is it possible then to have the server-side, based on the user's country of registration, control the level of access, features, and payment options for users on the iPhone?"

Yes, assuming you can get a reliably country of registration.

Once the server/application has the data, it can do pretty much whatever it wants with it, no? If the purchase happens in-app, then it is under your control. Only show/accept the payment options you want. If the features are only exposed from within/by the app, then it is under your control. Only show/allow the features you want. Well, if the above assumption holds anyway.

Of course, such conditionals do make the entire package more complex.