I have a product that has two different build, one for iPhone, and another one for iPad.
Is it possible to unlock features via In-App purchase in both with make the playement once from one of them?
You cannot use the same ID, howerver, you can manage information about which purchases have been made by which users on your own server, and update that information every time a user buys something. You just have to check on that server which purchases have been made.
Related
We are three guys, who have made a free game for iPhone, which has been available on the App Store for almost a year.
The app is a board game, where you create a user or login using your Facebook credentials. You are able to log out of the game and log back in with another account.
Now we have updated the app with the ability to upgrade the user to a premium user. Allowing personal and global game statistics.
But Apple is giving us a headache in the approval process, and refuses to accept our In-App Purchase. First they would not approve it, as it had no restore button. Then when we told them, a restore button was not required, as it was a consumable purchase, they now demand we change it to a non-consumable and add the restore button.
Consider this scenario if purchase was non-consumable.
User logs in.
User upgrades account to premium
User logs out.
User logs in with a different account.
User restores the previous purchase.
This would allow you to upgrade two accounts to premium, but with just one purchase.
Apple's argument is, that our users need to be able to restore purchases, if a new device is setup, or a device is restored.
But that is not the way it works. Users upgrade their accounts to premium accounts. Now when they buy a new device or restores an existing device, they just log in with their existing game account, and the upgrade will be available, because we on the server-side has marked the account as a premium account.
So my question is basically. Were we totally wrong, when we choose to use a consumable instead of a non-consumable. And if so, how should a non-consumable be implemented in order to be (potentially) purchased more than once with different game accounts on the same device?
And secondly, if we are correct about the usage of a consumable in-app purchase, what should we say to convince Apple, that we are on the right path?
If your premium account is something that your users have to buy only once then Apple is definitely right to ask you to switch to non-consumable in-app.
The scenario you described is quite possible (i had to face it too) but if you add server-side verification of in-app receipts before unlocking the premium feature (saving all transactions associated to a user) you have the chance to verify that the purchase is new or restored checking the fields original_transaction_id and original_purchase_date in the receipt data. This way you can see if the user restoring the purchase is the same that originally bought it (maybe checking its facebook user id).
Anyway, experience showed me that the chance of this happening is not really high and i wouldn't recommend implementing this check (although server side validation is almost always a must ;-) )
According to the 'Restoring Transactions' section of the In-App Purchase Programming Guide:
If your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
If your app contains non-consumable purchase, and if you don't include a restore button apple will not approve your app.
This has been made necessary by apple after June 2012.
So to answer your question: No, it seems that you must use restoreCompletedTransactions.
Hope it helps you.
I am planning to use subscription (auto renew) type of in-app purchase. My idea is to allow one subscription per device. (i.e.) if someone purchase the subscription on iPhone, he shouldn't be able to use same subscription on iPad. Instead I want to force user to new subscription for other device. But from in-app purchase what i understood is that, if user subscribe for a particular item, if he tries to purchase the same thing again, app store allows to user to restore already purchased item.
As per my current setup, all the downloads will happen from a separate server and I am going to keep all the receipts and content in that server. In order to implement this particular thing, what should I do in my application? Could someone help me on this?
Also if I want to limit download of data from server using in-app purchase for only 3 device? Beyond 3 I want user to make payment via in-app purchase again? How will I do this?
Thanks
Apple's In-App Purchase Guidelines state that you must support restoring subscriptions to all of a user's devices (see page 7).
Also consider if your content is episodic (such as a TV show or magazine) because that's a requirement for using auto-renewing subscriptions. For things like time-limited access to a certain feature, like voice guidance in a navigation app, you'd need to use non-renewing subscriptions.
I am using MK in-App Purchase and I want to make an application that have (let's say some books) and the books are getting added over time and each book the user have to buy it individually so how can I add with every book in-app purchase key for it without make an update for it.
I can't figure out a way so I need a step by step or a link for a tutorial for that.
I'm not sure if this would be the best way to set this up but if you are selling the books at certain price tiers (e.g. 1.99, 2.99, etc) I would set up a number of In App Purchases to reflect each price tier. Then when the user purchases a book match the appropriate tier to the book purchased.
You can set these up using the tutorial you already linked to in your question.
You will need to update your current app to accept in-app purchases and process them accordingly. After adding support for in-app purchases, you will need to re-submit your updated app to Apple.
I have personally used UrbanAirship in several of my projects. They offer tutorials on how to implement their in-app purchase solution into your app, which is quite easy.
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
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