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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With