IAP (iOS) Non Consumables Receipt Persistence

Hi I am currently testing IAP within Apple's sandbox environment (merged w production recently I believe).

According to the docs, owned non-consumables should always have receipts and only consumables' receipts are not persisted between app restarts. Therefore, I would expect Product.hasReceipt to return true for owned non-consumables. This is true when you make a successful purchase. However, Product.hasReceipt returns as false once the app restarts. When I try to purchase the item again, Apple verifies it as purchased already, and asks if I want to purchase it again for free. If we make the purchase again, Product.hasReceipt then returns true, but this also does not persist between app restarts.

I also tried refreshing the App Receipt during app start up using
extensions.GetExtension<IAppleExtensions().RefreshAppReceipt(OnRefreshAppReceipt,OnRefreshAppReceiptFailed);
However, it does not re-flag Product.hasReceipt to true.

Am I doing it wrong or has this been designed to happen within the sandbox environment?

 

I had the exact same question yesterday and emailed the devs. I'll update this thread with a reply as soon as I get one.

 

This is expected on the App store and Mac App store since these stores provide a single unified receipt containing the current state of ownership of all products the user owns. I will update the docs to make this clear.

Applications are responsible for deciding what a user is entitled to. The simplest way is to keep a record of purchase events in local storage, but ideally involves validating and parsing the application receipt for owned products.

 

Even though the iOS App Receipt is unified, the Unity Purchasing module is able to discern the receipt status of each individual purchase (within the same app run). Could a native query for those statuses via the purchasing module be implemented? Then the Product.hasReceipt flag can be really useful. In fact, maybe there could be a default receipt validation (can override w a custom one) under the hood, helping the average developer avoid the non trivial implementation of app receipt validation? That could prove really beneficial to developers trying to navigate IAP for the first time.