Following the Google Play docs, there is some cases in which a non-consumable item purchase is not confirmed right away but is set in a “pending” state: “For example, a user can create a PENDING purchase of an in-app item by choosing cash as their form of payment. The user can then choose a physical store where they will complete the transaction and receive a code through both notification and email.”
How does Unity IAP handles these pending purchases? Once it has been confirmed, the next time the user open the app, will IStoreListener.ProcessPurchase be called? Note that I am talking about pending transaction for non-consumable items (unrelated to the pending state of consumable items before consuming).
I ask because I recently had a user in this case, but he never received the item (IStoreListener.ProcessPurchase has never been called although he opened several time the app after confirming the purchase). I suspect that the problem comes from Unity IAP itself, because my implementation works well if the purchase is validated immediately.
Yes, the ProcessPurchase should be called!
If the application is running, then the PurchasesUpdatedListener will immediately get notified. Otherwise, we call the queryPurchasesAsync to fetch them.
This usually happens when:
-Closing and reopening the application
-Logging out and in of the Play Store
What version of IAP are you using?
We recently fixed an issue regarding this in 4.5.0 (but there was another bug related to this fixed in 4.5.1)
I would suggest updating to 4.5.1 (or 4.5.2 in a few days) if you aren’t already on that version.
In this case, you mention the user “opened several time the app”, is it possible an error occurred?
You might also be able to track down the purchase in your Google Console to confirm that it was processed correctly.
Hello Yannick, thanks for your reply.
I am currently using the v4.4.1, so maybe this is source of the problem. I know that the user opened several time the app from the logs, but I don’t know if it was just foregrounded or completely restarted. Probably foregrounded, as suggests the bug recently fixed.
I’ll update the plugin to 4.5.1 and see if the problem occurs again.