Search code examples
iosreceipt-validation

Understanding receipt validation and receipt refreshing in iOS

We have issues fully understanding the receipt validation flow in iOS.

Here is what we currently do (in development):

In applicationDidFinishLaunching and in applicationWillEnterForeground we validate the receipt on the server side, if there is no receipt or the receipt is invalid, we try to refresh the receipt and revalidate it.

Here are some issues/questions:

  1. What are the cases where there is no receipt available on the device ?

  2. Should we always issue a receipt refresh request when there is no receipt ?

  3. Why is this alert box sometimes shown on startup ? I understand this is shown on a receipt refresh request ?

Sign in required?

  1. When should a receipt verification happen ? We currently do it whenever a purchase is made to verify the purchase, is this correct usage ?
Solution
    1. In production a receipt is always available on device. In test after the first install there is not. So if you want to do a correct test, you must restore a purchase even if it doesn't exist a purchase on that user in the test environment. Why is that? App downloaded from the appstore always comes with a receipt even if they are free.
    2. Depends on the business logic you want to apply. If you are validating the receipt against a server each time the use launch the app, of course you need the receipt. If it is not present (but in production is always) or not valid, you can ask for a refresh or restore, but as far as I remember you should always ask the user first if he/she want to do that (can be a reason for reject). Restore and Refresh are not the same thing.
    3. This usually appear in purchase/restor/refresh. But also If the account has some pending requests because the app has crashed or you interrupted the debugging before the request end somehow, you will be bored by a lot of that. There is no way to flush them programmatically, just login until they stop. Of course it will not be a valid test.
    4. It's up to you and about the kind of purchase. If it is an autorenewable subscription, you can validate the receipt against a server, then store the the "end date" on the client and make another check after the date is expired. Pay attention that receipts can be quite big, because the have also all history values.