In-App Update ask for purchase it again - iphone

I am selling apps via In-App within my App, currently what I am doing is, when anyone has already purchased the In-App item, then at the time of update it ask for purchase it again, it doesn't charge any money but it asks each time for log in and password, Is any way to skip this log in progress, I want it should be updated without asking for purchase and log in password.

You'll have to cache the user's purchase history on disk somehow in order to prevent this from happening, otherwise you'll have to ask the user to authenticate with Apple at least once (through running a transaction restore or by re-purchasing your products).

Related

How to search for In-App transaction in Huawei AppGallery

I have published my app in Huawei AppGallery.
Users make purchases (In-App), I can only see the number of purchases the next day.
But I can’t verify the user’s purchase in any way, but only believe them.
In Google Play, I can enter the email or GPA number of the purchase and check when it was made and if the transaction was successful.
In Huawei AppGallery, I did not find this anywhere. Can you please tell me where can I find this option?
After all, it is the most important option for developers, I do not believe that it does not exist. I also need to know about the purchase this day, not the next day.
In the developer console, you could download the report as shown below
To track real-time transaction results, you could add "viewing the purchase history" in your app. Once this history is successfully obtained, you could either pass it to your server or save it in the app.
Alternatively, you could confirm the purchase by verifying the purchase token (from InAppPurchaseData) to confirm the purchase as well.
According to your description, you can go to Developer Center > My Report > Payment Report.
You can search for all subscriptions under your app by keywords such as the app ID, time, and order status.
https://developer.huawei.com/consumer/en/console#/myReport/payment

User can restore the same purchase on different accounts

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.

Consumable vs. non-consumable in iOS

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.

What happens if my non-renewing in-app purchase receipt is lost before it can be registered on my server?

I'm currently implementing a non-renewable in-app purchase and am a little concerned over the following scenario (or variation thereof):
User purchases my non-renewing in-app purchase. I save the receipt to NSUserDefaults, but before I have sent it to my own server for verification (and account functionality activation) the user loses signal/my server is down and in the meantime breaks their device/uninstalls my app (thus erasing the stored NSUserDefaults).
As far as I can tell you cannot restore a non-renewable purchase as with other types of IAP, so the user has lost the money they spent on that purchase as there is no way for me to know that it was ever made.
Am I missing something here, or am I to assume the above scenario is unlikely enough that I needn't worry about it?
Thanks
Ok, after some further reading it appears that the solution is to not call finishTransaction on the SKPaymentTransaction until I have had confirmation from my server. This way, the transaction should remain in the transaction queue across devices/installations until I have registered it within my own system.

App with Initial time-limited subscription then Auto-Renewable

I have an app that I plan to introduce soon, but I still have a couple of questions even after reading everything I could find. Maybe I'm just missing the obvious. The App requires a service subscription, because of the server monitoring and analysis required in the background.
I'd like the original App purchase to include a one year subscription to the service and then allow the user to renew (preferably I'd like to use the auto-renew option) towards the end of that period.
Can I just note the in the iTunes Store App description that the purchase includes a one year subscription, then prompt with a renewal notice after that period?
I've seen some comments about offering the App for free with limited usability, then doing an In-App Purchase, but I'd like to avoid having customers downloading the app, going through the initialization steps, but then not subscribing.
Any suggestions will be appreciated.
Can I just note the in the iTunes Store App description that the purchase includes a one year subscription, then prompt with a renewal notice after that period?
Yes.