Search Unity

Failure to ConfirmPendingPurchase after a Apple restores when doing backend receipt validations

Discussion in 'Unity IAP' started by vTrotta, Aug 11, 2021.

  1. vTrotta

    vTrotta

    Joined:
    Dec 3, 2014
    Posts:
    11
    Hey!

    We have an issue with the asynchronous (auto-renewable subscription) purchase validation process. We are using Purchasing 3.1.0.

    As per the following diagram, we return PurchaseProcessingResult.Pending in ProcessPurchase while starting a coroutine to validate the receipt and update the user status on our backend. When that is done, we call ConfirmPendingPurchase on that product.


    *https://docs.unity3d.com/Packages/com.unity.purchasing@3.1/manual/UnityIAPProcessingPurchases.html

    Our issue comes mostly from the fact that when an Apple restore is triggered, a (potentially very long) series of ProcessPurchase will be triggered. All for the same product and seemingly once per renewal receipt. The problem is that when we call ConfirmPendingPurchase on the Product we got as a ProcessPurchase argument, it seems to be ignored. I.g. on the next restart of the app, we'll still have the same long series of ProcessPurchase to handle.

    If this is not it, what is the recommended way to confirm pending purchases after a remote validation? The various IAP sample projects I've seen always complete synchronously by returning PurchaseProcessingResult.Complete.
     
  2. JeffDUnity3D

    JeffDUnity3D

    Joined:
    May 2, 2017
    Posts:
    14,446
    Yes, this is an issue we are aware of and working on. No ETA quite yet, hopefully within a month or less.
     
    vTrotta likes this.
  3. Doronn

    Doronn

    Joined:
    Sep 17, 2018
    Posts:
    8
    Hello.
    It's been over an year, was there any solution for this yet?
     
  4. Yannick_D

    Yannick_D

    Unity Technologies

    Joined:
    Feb 21, 2022
    Posts:
    235
    Hello,

    I have recently investigated this issue.

    First, you are correctly handling the pending purchase confirmation, they are not ignored.

    The issue is coming from Apple where they send back every previous transactions with an updated transaction id. Most of them can be safely ignored, but the important part is to process the right ones.
    There are certain actions that will trigger Apple to send the restored transactions on the next application start (even without requesting to restore transactions), but this is out of our control.

    We are working on a fix that will correctly identify these restored transactions and return the PurchaseProcessingResult.Complete without sending them to your ProcessPurchase if they were already acknowledged, but until then, the safe way is to continue processing them.