Here is a strange one for you :)
I have an iOS app that has a non-consumable product as a in-app purchase that the users could buy. It's kind of a lifetime subscription if you'd like.
The thing is that i had a bug in my code which allowed users to "subscribe" to my app by tapping on Restore Purchases button.
I fixed the bug now but i have a problem. Roughly 50 users are now subscribed but never payed for this service.
Is there a way to see if the user actually payed for this somehow? I would like to unsubscribe them if they did not pay.
The system works this way:
The user taps on Purchase, Apple takes care of the purchase for me and when processing the payment queue, if the purchase was a success i subscribe the user by adding their iCloud ID to my database. So the only piece of data that i have is their iCloud id and nothing else. I don't know which iCloud ID is a "payed" one and which is "cheating" :)
You can obtain the receipt from the user's device and check with Apple's endpoint to see if the user has a valid purchase. Ideally you should take the receipt from the app and send it to your server to perform the verification in your backend.
Check this documentation to obtain receipt from the device - https://developer.apple.com/documentation/storekit/in-app_purchase/validating_receipts_with_the_app_store
Check this documentation to call verify the receipt with Apple's endpoint - https://developer.apple.com/documentation/appstorereceipts/verifyreceipt
I have a side project and I recently worked on my receipt manager to make it stronger and to relies more on the receipt of the app rather than persistently storing a value after a transaction.
However, there are 2 main points which although I read Apple docs and other answers on the web, I'm still confused about:
1. When a user restore their purchase, does the receipt get refreshed?
I made several tests in sandbox, and I have seen that when restoring, the receipt gets refreshed, and when I verify the receipt through the iTunes server verification, it returns a JSON including the latest transactions. This is very helpful because even if I close/open the app, the app receipt is updated and I can always verify it without refreshing it.
However, in production, this didn't work. The app receipt wasn't refreshed after restoring purchases and my users got asked to restore purchases continuously. Can anyone answer on this point?
2. Does the refresh receipt request triggers an alert asking for the Apple ID's password in production?
From the previous point, I thought ok, I will force receipt refresh after a user restores their purchases. However, in development / sandbox, I get asked to insert my sandbox user's pass every time I try to refresh the receipt (although I could restore purchases without a password request before asking for the refresh). I read a lot about this and someone says that might not happen in production. Does any of you have a clarification on this?
Note:
I know that when restoring / purchasing I get back a transaction with the receipt, however, I need to use the App Receipt to verify transactions (and this is also what Apple says to do).
Thank you in advance.
1. Refreshing the receipt
In theory, calling restore purchases should get the latest receipt. In the instances where you are experiencing issues, take a look at SKReceiptRefreshRequest. Typically, I use this in production when a call to restore purchases has encountered errors.
Use it wisely, triggering that API can lead to showing the Sign In prompts for the App Store.
2. When is the user asked to sign in?
Sadly, I have seen this vary so I cannot give a definitive answer. More often than not, a call to restore purchases should not trigger a sign in. Explicitly using SKReceiptRefreshRequest will.
If the user is not signed in to the store, calling any Store API like attempting a purchase or restoring purchases could trigger the sign in flow.
What Apple Says
From the docs
Refreshing a receipt doesn't create new transactions; it requests the latest copy of the receipt from the App Store. Refresh the receipt only once; refreshing multiple times in a row has the same result.
Restoring completed transactions creates a new transaction for every transaction previously completed, essentially replaying history for your transaction queue observer. Your app maintains its own state to keep track of why it’s restoring completed transactions and how to handle them. Restoring multiple times creates multiple restored transactions for each completed transaction.
My Recommendation
Store the hash of the last receipt you used on device. You can use this hash to check against the latest receipt so you know if anything has changed. Whenever your App resumes you can always check if the current receipt hash is different from the last cached value.
Try and submit the receipt as soon as possible. Typically when the App has launched.
If a user tries to manually restore purchases, I would start with a call to restoreCompletedTransactions. This can trigger an App Store sign in but is often less likely. Most of the time this is enough as the receipt on the device is often pretty up to date.
If the user tries another restore purchases, OR if the call failed, then move to SKReceiptRefreshRequest to guarantee a fresh receipt.
When using SKReceiptRefreshRequest, I would recommend wrapping this behind UIAlertController. I normally show something that indicates it has failed and have a "Retry" button that uses the request. This will trigger a new store sign in.
Use restoreCompletedTransactions to get a playback of all completed transactions the device is aware of.
When a user restore their purchase, does the receipt get refreshed?
Yes, it should. But it also sounds like you're doing some server-side validation? If that's the case, you can send any receipt from the user to the /verifyReceipt endpoint to get the latest status. You don't need to send the latest receipt, since /verifyReceipt will also refresh it.
Does the refresh receipt request triggers an alert asking for the Apple ID's password in production?
There's no clear Apple documentation on this, but it definitely will if there's no receipt file present in the app (rare in production). But if you're doing server-side validation (see #1), then you can send up any receipt you have, no need to refresh it. So you're only refreshing the receipt if nothing is present, which will trigger the sign-in. Keep in mind a receipt file is not present on the device after installing in sandbox - only after a purchase. This differs a lot from production where a receipt file is generated after installation.
From what it sounds like you're trying to do, my recommendation would be to check if any receipt file is present at launch, send it to /verifyReceipt to get the latest status for the user and cache the result. You can do this on every app launch.
In a perfect world you're storing the receipt server-side and keeping it up-to-date there, but you mentioned side project so that sounds like overkill. However, an out-of-the box solution that correctly implements all of this and will scale with you - such as RevenueCat - is another alternative (Disclaimer: I work there).
After many tests and after I sent my app in production, I'm now able to answer my questions properly:
1. When a user restores their purchase, does the receipt get refreshed?
YES, this is immediate as for Sandbox, BUT the problem is that the receipt DOESN'T include non-consumable purchases.
This means in other words that the receipt will include the purchased subscriptions, but you won't find purchases of non-consumable products.
However, when the user restores or purchases, you get the transactions in return, and you can extract the non-consumable products, and store this info somewhere like UserDefaults or Keychain, so you can use them when the user opens your app.
For the rest, the best approach is to always validate and check the receipt when the app is opened.
2. Does the refresh receipt request trigger an alert asking for the Apple ID's password in production?
YES. For sure it does the first time.
Thank you to Daniel and enc for their answers that can still be useful.
My problem is, the users cannot get the non-consumable item by redeeming the code.
I can confirm the non-consumable items can be bought correctly.
I used the app receipt to check whether the user owns it. I'll find through all the products to see if there's one the product id is matching.
I cannot find any useful docs to debug the redeeming process. I don't even know if there should be a callback when the app starts. Like the transactions are not completed.
How is redeeming handled behind the scene?
If the app is open after I redeemed a code, how should the app know the user 'bought' the item? How should I know when to send them the contents?
If the users try to buy the item they redeemed, they are told they can get it for free, and I see the purchase succeed callback. But then I check app receipt, the product still not exists. I got these logs from the users.
By the way I'm using in_app_purchase plugin from Flutter. And for checking the app receipt I'm using https://github.com/robotmedia/RMStore.
Products redeemed with a promo code will appear on the receipt just as a purchased product would - you won't be able to differentiate from the receipt a purchase vs promo code.
There isn't a callback on the device for promos specifically, if you refresh the receipt or the user restores transactions you should see the product in the receipt.
I'm implementing an iOS app with non-renewing subscription. Not much relevant information was available online; so I seek your guidance.
A use case which worries me the most is when a user purchased the subscription once and then immediately after purchase it again to extend the duration of service (see such scenario here). What if that user were to refund the first purchase, leaving the second one intact? Is this even possible in practice, or am I just too paranoid?
Assuming the above case is possible, my app will run into a problem because, as far as I know, verifyReceipt only returns the latest, good receipt (watch Managing Subscriptions with In-App Purchase in WWDC'12).
I find nowhere Apple provides relevant information about refunding policies.
(Auto-renewable subscription seems to rule out this case as a renewing action is taken care by iTunes automagically and it seems not possible to extend this type of subscription until iTunes allows it.)
verifyReceipt will not only return the latest good receipt, it will also tell you if the receipt you submitted for verification is good. So if you're concerned that a user may have cancelled* a transaction, then submit every receipt you're questioning.
*But what do you mean by "cancel" the first purchase? Do you mean when they tap "cancel" instead of "buy?" Well then the transaction won't go through and you won't even get a receipt.
Or do you mean when they request a refund? I don't know any other way they can cancel a purchase.
Edit:
If you're referring to refunds, there's no way for a developer to tell if a user has been issued a refund. The assumption is that Apple expects you to continue to deliver services to that user regardless of the fact that they received a refund. Your receipts will probably all verify correctly regardless of the status of a refund.
I am implementing a digital magazine project for a client. Auto-renewable subscriptions for a period of 3/6/12 months have been included as a feature. My question is while using in-app purchase, is there any way for the server to map the user?? Anyway to identify a particular user is using it? I have done extensive research and know that apple doesn't allow the user's apple-id to be mapped?? Is there any other way to identify a particular user?
The problem arises for subscription. If an user has undertaken a subscription for let's say 3 months, then my app has to show DOWNLOAD button for all the 3 months instead of the regular BUY button. But when a new magazine is launched on to the storefront, how would the app know that this person is subscribed or not and convert the BUY to DOWNLOAD?
When a user buys a subscription, you should store the receipt on your server. This receipt, in a way, becomes your way to identify the user's account. Whenever you want to check the status of an account, send that receipt to iTunes for verification and it'll respond with the latest receipt for that subscription, along with the expiration date. Since you've made a note of which specific device that receipt came from, you can provide the proper UI to that user.
Now, if the user installs your app on a new device they can tap a Restore button that you've provided in your app. That button will call restoreCompletedTransactions which will send all the Auto-Renewing receipts for that user's Apple ID to the device.