views:

109

answers:

3

Hello,

We have developed an application that allows a user to download audio content. The use of application itself is free, but we charge for the content. In our current business model, we accept payments using premium-rated SMS (which increases the in-app user's balance), however, Apple rejects the app since they do not allow this model for their applications.

Is there any other way (except In App Purchase API) we can accept the payments with?

A: 

The easiest was to look at this is to work out why they refused the application, which is because it is not in their interest. You are selling a product to their customer and they are not getting any commission. In order for them to accept the app I would imagine that you will need to provide an in app purchase mechanism, but you could do this in addition to the Premium SMS as long as the app doesn't send the message

Liam
A: 

Another option would be offering the same service via an ordinary website and then offer the app to allow users accessing their existing accounts. Take dropbox as an example - they offer paid memberships which you purchase on their website. The dropbox app itself is free but lets you access your dropbox account, for which you paid elsewhere.

In your case maybe you could offer "credits" for purchase (payable by premium-rated SMS) on your services website which the user could then spend by accessing his account from within the app.

This is less "direct" (requires the user to visit your website to pay for the content he will download later) and I wouldn't even bet on apple's approval (if the website appears to be merely a place for buying credits without further functionality, they'll propably reject the app too for circumventing in-app purchase), but then again, there are (propably) no alternatives. However, I'd talk with apple about this option before implementing it, to avoid wasting time and money. After all, in-app purchase is the way apple wants people to go if they want to spontaneously purchase content using only their device, so they'll defend it.

Toastor
That's exactly our business model which was rejected by Apple.
Eagle
Oh, I missed the point, then... From what I read I thought your service was based on iPhone only. Sorry!
Toastor
I thought you got your payments via Premium SMS? and not a separate website. The other thing you have to be sure of, is to not have a "upgrade here" or anything in your application. Since any "upgrades" need to be done through their in app purchase. The DropBox app, if you run it will allow you to create an account and it is free. You have to go separately to their website to purchase or update the account.
christophercotton
+2  A: 

Apple will only accept in-app purchases for this type of business model. Even then, you still have to submit each and every "in-app update" for approval at least a week prior.

Like Liam said, they want their piece of the pie too and they also don't want people slipping something past them (for instance, highly offensive content, pornography, etc.)

Per Apple:

You can create In App Purchases on both Free and Paid applications. Every product you want to offer in your store must first be registered with the App Store through iTunes Connect. When you register a product, you provide a name, description, and pricing for your product, as well as other metadata used by the App Store and your application.

There's no other way with this type of business model. More info here around page 116

iWasRobbed
Does that mean that I will have to submit each and every piece of audio content for their approval? These are the human-read articles from various newspapers and magazines, there will be some hundreds of them per week and they expire (i. e. lose their value) exactly the next week. They are not in English, too.
Eagle
As it stands now, yes. If you look at the "Ambiance" app (which another developer that frequents here made), they have created a separate in-app purchase object for each and every sound. I would recommend going the "Subscriber" approach and just factoring in those fee's into the subscriber cost similar to how a newspaper might to grant access to ALL content. If you want my honest opinion, I would much rather pay a subscriber fee than pay 99 cents for something that I may end up not liking and then having to pay **another** 99 cents for **another** article/sound clip/etc and so on
iWasRobbed
Best description of what you can/can't do: http://developer.apple.com/iphone/news/pdf/in_app_purchase.pdf
iWasRobbed
Subscription was one of the options in our current business model. If I go with the subscription model, will that mean that I will still have to approve every sound? Sorry if it was covered in the doc you provided, I just failed to find this info there.
Eagle
I think it really depends on how you present the data (i.e. ask Apple for 100% certainty). If it's something like the Wall Street Journal app where it's web based content that gets updated daily, I think it's okay as long as you don't charge extra for premium content which would circumvent Apple getting their percentage. You could also use something like Urban Airship to host/deliver your content. The only downside of subscription based is that you, the developer, have to handle the subscriptions on a monthly basis.
iWasRobbed