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.
Related
I'm writing an iPhone app. The question is regarding the new rules restricting purchases inside the app.
So: the user charges their account up with 'credits' on the associated website using real money via a payment provider. The user installs the app and logs in using the same account as is used on the website: they cannot use the app without first logging in [edit: although they can register an account without adding any credits.].
The purpose of the app is to build up a report about a property, which can then be emailed out, or exported to their account to appear on the website. The report can be built up without using any credits. However, to export the report to the website or email it out, these credits must be expended by contacting the server and debiting X amount from the user's credits.
Here's the question:
The user's account is debited whenever they do this export. Only if/when the user's account is out of credit does the app complain that credits are low (otherwise it doesn't mention them), and it tells the user to go to the website to top-up their account to proceed. Remember that they can't login without an account, which can only be created on the website, and the website explains this.
From the guidelines:
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes
to a web site to purchase a digital book, will be rejected
So, my app does not provide a link to the website when explaining that their account is low on credits, it just says that this is what is needed to proceed. The export function, however, does require that the user has topped up their account, so in a sense this does fall foul of the next rule:
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
I'm somewhat worried that this credit currency will fall foul of these recently-tightened rules, does anyone want to please reassure me (or, break the bad news)?
P.s. Spotify requires that users pay a subscription (on their website) to use the iPhone app. The difference between them and the above is that their subscription is unlimited-use whereas the above has a per-use charge.
Thanks in advance,
Ian
When you submit your app, include a tester username / password to the App Store. Fuel this account with a few million credits so they don't see the reference to Credits Low. There are many apps that get rejected just for having a login - if you make the reviewer's job easier by having a user/pw they can use, it'll increase your chance of acception.
If you app does get rejected, it means you have to change your model anyway. Actually - you might just be able to add 'Buy Credits' as an in-app purchase to appease Apple. Just make sure the credits in-app cost the same or less than externally - as far as I can tell, Apple will let you keep external purchases around as long as they cost the same or more than in-app purchasing.
Additionally, make sure your "low credits" alert doesn't link to an external page to buy more credits-- this may be frowned upon.
I'm sorry to break it to you but it definitely is a grey area and could potentially get your App rejected because you are asking the user to go to an external source to purchase credits which means Apple is cut out from any potential revenue.
I've had first had experience with this sort of rejection, all that was the issue was the description pointed to a web page where you could buy the product but Apple still had a hissy fit about it and added 2 months to the approval time and it ended up with me removing the link.
You could warn the User that their credits are running low, however pointing to the page to purchase them could potentially be the tipping scale.
On the other hand, there are some apps which make it through but there is no certainty. You are at the mercy of the reviewer in the end... You could potentially ask Apple Developer Support for any further information after describing your scenario.
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.
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.
I have a website which sells a product to the user (downloadable). I am creating an iPhone app and want to be able to sell some of the products using the 3.0's in-app purchase.
Now the documentation mentions that anything you want to sell has to be uploaded to iTunes Connect and approved by Apple. But I want to be able to keep adding products to be sold by my app on a daily basis.
I have a web service to get the list of products from the website. Is it possible to include in-app purchase to let user buy this stuff from within the app but without having to add them to iTunes Connect?
As I understand it, no - all the things you want to sell via in-app purchase run through a vetting process similar to that of the apps themselves. Apple won't allow, for example, a "photo of the day" application if you can in-app purchase pornographic photos to be sent to you daily.
What you could probably do is submit your app with a backlog of in-app purchases, five or six days ahead of time, then consistently be submitting your daily items ahead of when you want them to be available. Not sure how reliable the review process is, or whether this will work for your situation - just a thought.
Nekin,
I think you have to use the type as consumable (in app purchase) product as each time the product has to be purchased. Once you purchase a book, then you can mark it as purchased in your local app database and that way the user need not buy the same book as you can check it in the local app database before connecting to the in app purchase payment request and this way the inapp purchase products can be dynamic and can use as many books but the list of books should be from your server.
You can keep updating the server data with more number of books.
Thanks,
Vijay