I want to submit a free app with In-App purchase in the Appstore which can be available in all geographies and not restricting to any particular geography.
However,I do not have financial account for all geographies,say, i just have a account in US .So, as i am making the app freely available for all geographies but do not have financial accounts for all geographies,how can a user outside US buy any enhancement through In-App purchase? Does Apple restrict such transactions any way? Or, does Apple reject such applications?
Supposedly,If this app gets approved by apple and goes to app store and any user outside US downloads this app and tries to buy any enhancement using In-App purchase, how will the financial transaction happen?
I may be way off here but doesnt apple handle all the payment transactions themselves? I thought they processed everything, took their 30% cut then gave the developers their share. If that is case, they probably handle the international transactions and give you your share the same way they would any local transaction. It wouldnt make sense for you to have to have accounts all over the world in order to sell an international app.
Also, I dont believe this would have any effect on weather the app is approved or not. Apple wants as many people doing in-app purchases as possible so they can make as much money as possible.
Related
Is there some new subscription mechanism requirement on iOS? So far we handled the subscriptions without involving Apple, but this (https://developer.apple.com/appstore/in-app-purchase/subscriptions.html) is saying something different:
If you offer auto-renewable subscriptions, you can also use other
methods to acquire digital subscribers outside of your app. You can
sell digital subscriptions on your website or provide free access to
content for existing subscribers. In these cases there is no revenue
sharing since Apple was not involved in the transactions. Developers
keep 100% of the revenue. If you would like to make a subscription
offer outside of the app, the same (or better) subscription price must
be offered inside the app for users who wish to subscribe from within
the app. In addition, you may not provide links in your apps which
allow the customer to purchase content or subscriptions outside of the
app.
I understand the In-app purchase is mandatory for one-time payments, but so far we were not forced to offer subscriptions over In-app purchase mechanism...
BR
STeN
My historical understanding as well as my understanding of that specific text is that, yes, they require you to offer the IAP subscription inside your app since you're offering it outside as well. I think you've just gotten lucky so far that they haven't noticed.
I'm considering posting an app to the iphone app store, but I'm curious before I start paying them for the priviledge of posting the app, whether they provide instant payment notification to a url?
Generally, I've used paypal in the past for applications where right after payment my web site is secretly notified of a purchase. I take this notification, with the users email address and product purchased, to send the purchaser information required for the application.
Is this possible with apple? With the iphone app store? What about the upcoming mac store?
thx
No. Apple handles all contact with the customer, including delivery of the app. At the end of each day, week and month they give you summaries of sales of each product in each country. It's nothing like selling with PayPal. The iOS and Mac App Store are exactly the same in this regard.
The nearest you can get is having your app connect to your server when it first runs, although if you're doing this for no other reason than to track your users, you'll have to check it's allowed under the developer agreement.
First, no, you do not receive instant notification. You can grab a daily report on the web the following early morning (in the US), you can use the free app that Apple provides to retrieve the information, or you can use a variety of third-party tools to do the same.
Second, you will never receive any information whatsoever about the people who buy your app, so no, you can't send purchasers anything.
The Mac App Store appears to use the exact same arrangements.
If you use in-app purchase, you can get an instant notification to your server for the in-app purchase, but not for the initial download of the app.
If you just place a paid app in Apple's App store, you get no direct sales or customer information of any kind, only after-the-fact daily and weekly sales trend estimates, and monthly sales reports a few weeks later. Then Apple then pays you 70% of what they reported up to 45 days after the monthly close. You don't pay them. They pay you. And with over 300K apps in their store, and no other store doing anywhere near as well, they need no privileges granted from any developer. It's more like take it or leave it.
I'd like to sell products through my application (insurance policies) and I don't want to use the in-app purchase mechanism as it would mean sharing 30% of the product price. Instead I would like to provide the user with a page to enter his/her credit card details and perform the credit clearing through my own self-developed secured services.
My question: is selling products which are not content or features, using my own purchasing system, prohibited by Apple or appstore policy?
Obviously, I am not a lawyer, but I think you’ll be OK. Here’s my interpretation of the three relevant rules from the developer guidelines (emphasis mine):
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected.
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.
The first rule prohibits you from unlocking anything inside of your app with something other than the App Store. This would prevent you from, say, making a game that downloads new levels from your server based on your membership to a website.
The second rule prohibits you from, say, making a game and enabling PayPal in it to unlock more levels. Apple wants you to use in-app purchase for that.
The third rule—and this is where it gets interesting—prohibits you from using in-app purchase in an application to buy “physical goods” or “goods and services used outside of the application.” Nowhere does it say, however, that you can’t use other purchasing systems.
With that third rule, I think what Apple is saying is this: anything that runs on the iPhone must be purchased through the App Store, and everything purchased in the App Store must run on iOS. For something like insurance, which isn’t new functionality in the app, I think you’ll be OK. This is absolutely worth an e-mail to Apple’s technical support staff, but if you look at Amazon’s app, you can purchase physical goods using Amazon’s checkout system.
Quoting from Apple's Guidelines - 11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
So, you should be fine. This is validated by apps that are already in the Apple app store, such as Groupon, Fandango, Chegg and others that charge users credit cards for physical goods or goods consumed outside of the app without passing the transaction through Apple.
It would be great feedback for everyone to hear whether you had any difficulties with Apple when publishing your app or not.
11.10
Insurance applications must be free, in legal-compliance in the regions distributed, and cannot use IAP
https://developer.apple.com/appstore/resources/approval/guidelines.html
Also read: http://www.quora.com/How-do-eBay-and-Groupon-get-around-Apples-in-app-purchase-system-despite-being-native-apps
In general you can sell physical products via an app. You cannot however use the InAppPurchase mechanism for this, but are required to use your own payment mechanism.
Ruling on this seems somewhat unclear from the guidelines. Would be interestig to hear whether your app got accepted.
We just recently submitted an app that featured in-app purchase of non-digital goods and everything went through without issue. Take a look at the following to get more insight:
Does Apple test purchase of physical goods during their app approval process?
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?
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
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.
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
Is there a programatical way in which an In App purchase is refunded back to the user?
I have an application with a certain buyable feature. The user buys it but somehow doesnt like it. Is there any programatical way in which I can make the user get back his spent money?
I don't think it is possible. This is the same as with buying an app from the AppStore - you cannot say that you did not like the app, return it and get your money back. This is one of the reason why there are free lite versions of some apps. This allows users to check the app for free before they buy it. Maybe you could use the same mechanism in your app? Give some content for free and if the users see that it is what the need they could buy more of it.
No. The user will need to contact Apple Customer Services who will then decide whether or not to issue a refund. The refund will be taken from your apps earnings, I believe.