I am implementing In App purchase in my application.
What I want to do is that I have few features that are locked and once user click that feature it will ask to buy that product and once they buy, the feature will be unlocked. But before that I have to check whether that particular product is already purchased by the user or not. If its already purchased I don't want to show the alert for buying that product.
How to achieve this.
Ideally you should save the information about what has been purchased when it is purchased, so you can just check it yourself. In the event of an application reinstall it is possible to query the app store to see all your past transactions.
If you want to get a list of previous transactions from the store you use -[SKPaymentQueue restoreCompletedTransactions]. The restored transactions can be verified just like normal transactions.
Related
In my app user can log in with a phone number (account) and purchase auto-renewable subscription. This subscription will be associated with his account so he can log in on another device and see his purchased items. The problem is that he can log in with different phone numbers (accounts) on the same device where the subscription was purchased and restore purchases. So he can restore purchased item for other accounts using the same subscription.
Question: Can we remove Restore Purchases functionality in that case? If we can't how can we handle such situations?
I heard that all apps in Store should have restore purchase button but it doesn't make sense in our case.
See this answer here: https://stackoverflow.com/a/54153169/3166209
In summary, you're required you to have restore functionality, but it doesn't have to be implemented through StoreKit. You'll notice large, cross-platform, subscription apps like Netflix don't have a restore purchases button anywhere for the exact reason you mentioned.
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.
IN BUILT_IN MODEL
If i purchase feature through Non-consumable for on application,if i delete it,
If i purchase it again,will apple remember my user_id to purchase it as free?
IN SERVER MODEL?
suppose the app uses server model, may the server use apple to remember that user?
any help please?with explaination?
If your user purchases an item and then loads your app onto another device and purchases the same item, it will not charge the user for the purchase. The answers to your questions are in the docs here:
http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html
In particular, on the chapter on making a purchase the docs say:
If the user attempts to purchase a
nonconsumable item they have already
purchased, your application receives a
regular transaction for that item, not
a restore transaction. However, the
user is not charged again for that
product. Your application should treat
these transactions identically to
those of the original transaction.
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