Unfortunately there does not appear to be a work around at this time. Your refund process looks valid.
Sorry, didn’t get why refund process looks valid.
- Try buy Item A, switch off internet before Google response received.
- Get “No internet” Google error.
- Turn internet on again, no processPurchase from Unity. User is charged money, but gets no content
- Try buy item A again, get “Already purchased” from Google and “User cancelled” from Unity every time.
- Go to Play Console and refund transaction for Item A. Money is returned to user.
- Start app again - get ProcessPurchase from Unity on the transaction that was refunded on step 5.
- Result - user gets his money back, but the content unlocks because Unity sends successful purchase after refund.
Why is this behavior valid? Unity sends successful purchase event ONLY when I refund the blocked transaction. So user gets his content that was blocked on steps 1-4 only after getting his money back
I was referring to your Upd: comment as a valid work around in the meantime.
What exactly is valid in user getting both money back and paid content for free? I have to refund users’ money, because they didn’t get content, which is blocked by Uniy bug. And after I refund Unity sends successful purchase on this content. So user gets both money and content. How this can be valid?
You are not following me. I simply meant that your Upd comment makes sense, should not create additional issues, is unfortunate but should work, is far from ideal, etc etc. It is a valid WORK AROUND, not a valid solution.
@JeffDUnity3D just following up, wanted to confirm that regarding the bug I described above, that the fix from the IAP team will be which one of the following?
Scenario A:
to not charge player for a transaction that timed out due to poor network correct?
Scenario B:
Interrupted transaction become a pending transaction and on next IAP initialization it will be attempted to be completed. AND Unity IAP will always fire OnPurchaseFailed event for such a transaction for failureReason.ExistingPurchasePending.
Asking because in order to know what inventory to award the user, we keep a pendingPurchasesCache that contains sku and inventory info for a purchase. As a purchase is initiated, we add to the cache a record of the purchase for what items are bought (our purchases are dynamic). For Scenario B, if the failure reason is something like **User Canceled** (as it currently stands in 1.20), we wouldn’t be able to apply the inventory for the user because the purchase is no longer in pending purchase cache. We remove a purchase from the pendingPurchaseCache when Unity IAP fires the OnPurchaseFailed event (for any failure reason other than ExistingPurchasePending).
So just wanted to clarify on the fix that’s coming. thanks!
Hopefully the fix will address both issues.
@JeffDUnity3D thanks for your reply. Hmm the fix should be either A or B right?
Also thought maybe worth issuing a bug report on this, is it sufficient to include the standard IAP project with our descriptions of step to repro? I don’t think in this specific case our purchasing code has any relevance.
A bug report is not necessary, we are already working on the update. Regarding B, any pending transactions will trigger ProcessPurchase on next app launch. No failure callback would be expected.
any pending transactions will trigger ProcessPurchase on next app launch. No failure callback would be expected.
Do you mean that at Step 3 of my repro description, we get the Error: Time out from Google play native dialogue and then no callback will be fired through Unity IAP at that point? neither success or failure
No failure callback would be expected at app launch for pending transactions, only ProcessPurchase would be called. You can expect either ProcessPurchase OR OnPurchaseFailed to be called in any situation, but not both.
You can expect either ProcessPurchase OR OnPurchaseFailed to be called in any situation, but not both.
Exactly what I would expect too. The question is what failure reason would be expected for a network connection error.
Actually may I suggest adding to the documentation what each of the Unity IAP failureReason enums correspond to the native billing error codes?
i.e this page https://docs.unity3d.com/ScriptReference/Purchasing.PurchaseFailureReason.html
ideally would also have each enum refer to an error code from Google Play's billing system | Android Developers
Handling errors | Apple Developer Documentation
Understood, we are still discussing how to handle poor networking behavior. We are trying to avoid the need to check the network prior to every call. I will pass along your comments to the IAP team, sorry for the confusion.
thanks @JeffDUnity3D !
Wanted to follow up with one more observation/question: On Android, a timed-out transaction due to poor connectivity (as described in repro I provided above) did get called ‘ProcessPurchase’ on app/IAP re-launch (with good connectivity) but only after 24 hours - 3 days.
@JeffDUnity3D any idea why the time frame varies? Would expect it to be immediate when IAP initializes. On iOS this seems more reliably immediate by restarting the app.
1 Like
@thingiebox We have no control over this behavior, it’s up to the stores to initiate these callbacks. Can you elaborate 24 hours - 3 days? Does it consistently but eventually show up, how many tests did you run?
Hi there, our team is having the same problem. After about 1-3 days, the iap product finally got consumed, but it’s not consistently, it only happened on 1 device.
@JeffDUnity3D I see. thanks! Yeah on iOS, after relaunching the app in good connectivity, there are always finish transaction: IDxxxxxxxx calls to consume the products. On Android, all the many many tests we have done with simulating a ‘timeout then already own item’ error, will not see the transaction ‘finish’ call on app relaunch. Sometimes it will occur when restarting after 24 hours, sometimes after a few days.
We are hoping that the next release will address this issue.
2 Likes
Thank you @JeffDUnity3D , any rough timeline for the next release?