After updating Unity IAP (3.2.3 → 4.5.1), we have started seeing a large number of “initialization failed” errors of the type PurchasingUnavailable.
We log these errors to our backend each time we receive an OnInitializeFailed callback from Unity IAP.
While using our previous version of IAP (3.2.3), these errors were exceptionally rare.
With Unity IAP 3.2.3, we had a weekly total of just 2 OnInitializeFailed(PurchasingUnavailable) events.
With Unity IAP 4.5.1, we have seen upwards of 400 events logged per day. On one day, we logged 1480 events from 40 unique users with 1000 of these logs coming from just one user.
All logs are coming from Android users but for various device types, various Android OS versions, and various countries.
These users all have GooglePlay available and we have no crash/exception logs for them.
The events are not sporadic but come as continuous streams from the affected users, we are seeing instances where as many as 18 failure callbacks are received within one second from one user. We have logic in place so that if initialization fails we will not re-attempt it for at least 1 second so multiple OnIntializeFail callbacks should not occur simultaneously.
It seems most likely to us that IAP 4.5.1 is generally mishandling some uncommon PurchasingUnavailable cases and either repeatedly calling the OnInitializeFail callback for a single initialization failure or internally retrying continuously and calling the OnInitializeFail callback every cycle.
Very similar to my situation except I have noticed only on our Amazon platform does Unity IAP fail to initialize with a reason of PurchasingUnavailable. However, if I downgrade back to Unity IAP 4.1.5 purchasing works again.
Environment
Unity Editor: 2020.3.16f1
Unity IAP: 4.5.1
Unity Services Core: 1.4.0 (I am upgrading to 1.6.0 now and will test shortly)
Thank you for the detailed report, I was able to identify the cause of this and we will look to solve this soon.
On GooglePlay, there’s a case when attempting to retrieve products while the Google Play Store has failed to connect that will call the OnInitializeFailed once per product. We will look to reduce this to only one callback.
For the issue on the Amazon platform, would you have a log to help us identify it better? We havn’t done much work on Amazon lately and I’m not seeing any changes since 4.1.5 that could cause this.
Thank you for looking into this for us so quickly.
To supplement the initial report, we have only 6 products configured right now.
It seems like the identified one callback per product issue explains some of the simultaneous callbacks but there may be a little more to the problem.
Until IAP 4.5.1, we had very few PurchasingUnavailable logs but now many users are affected
Even if a callback is made for all 6 products, this should only happen once. Most of our cases are more than 6 some are up to 1000 PurchasingUnavailable events.
In 4.2.0-pre.1, we fixed the following which is why you are seeing more cases than before: Fixed OnInitializeFailed never called if GooglePlay BillingClient is not ready during initialization.
Can you confirm if those are happening all within 1 second (on the same Initialize call) or if there’s 6 per call to Initialize?
I’ve taken a look at the code again and it looks like it’s the same call that would cause the OnInitializeFailed(PurchasingUnavailable). As long as it’s within the same Initialize call, we should be able to limit it to 1.
I understand. That explains the increase in unique users seeing this issue.
We don’t currently have a log for when we call initialize on IAP, so I cannot be 100% certain how many times the client is calling initialize yet.
However, I have done a logic review and run a test build. Both of which found that we only call initialize on two occasions:
i. Once, shortly after the app launches
ii. Once again if IAP is not initialized (StoreController != null && StoreExtensionProvider != null) when the user manually requests the store by clicking a button. The user has to first confirm a retry popup so there is a physical limit on how many times this can occur.
Based on this, I understand that in the vast majority of cases init is likely to only be called once, and in other cases where the user requests the store after a failure, it is likely that the user only tries two or three times over maybe 10 seconds before giving up.
When checking the logs I made the following observations which lead me to believe that the potential 6x callback is unrelated:
iii. I cannot find any instance where 6 OnInitializeFail events are received together.
iv. Many of the logs seem to come as two logs / one second.
v. The count is very random, from 2 to up to 155 OnInitializeFail events in the same second. The 155-count user continues streaming these fail logs for another 13 seconds after this.
For data protection reasons I’ve had to strip a lot of information but I can share a day of logs for example of what we are looking at:
Thank you for taking the time to provide us with all this information!
We will keep investigating this to better understand how we’re getting more than 1 call per product per init and make sure we fix this properly.
Hello,
We having same issue with Purchasing (4.4.1). We use the same codebase from another project. The other project works just fine with version (4.0.3).
We have 564 unique users with around 6.5K fail event. We want to upgrade the package but as I can see, the issue present 4.5.1 too.
Hello, we are also seeing a marked increase in purchasing unavailable errors leading to an increase in failed purchase user complaints starting on about the seventh of December. (IAP Version 4.4.1)
We are also seeing multiple error responses returning at the exact same time. Up to eight in the same millisecond.
Hello,
What version of IAP were you using previously?
The only thing we changed on our end was that those error were previously not sent to the OnInitializeFailed, but that should not have any effect on the behaviour since before it was failing silently.
The other possibility we see is that something in Google Play Billing v4 changed, but we havn’t been able to replicate on our side yet. Any new information is welcome!
The solution that seems to work so far is to ask the users to log out from all the accounts on their device and log back in.
For the high volume of errors, this is something we are aware of and we will be fixing this.
This is the only workaround we currently know of, but we are looking at different possible solutions with a client as we speak. A better solution is being worked on.
Feel free to provide your logs or any relevant information if you are also encountering this issue.
Hi all,
There is still no direct fix for this issue yet but it is still under investigation. Feel free to share the details of your investigation as well, it will help to solve this.
This is still under investigation, but we miss details to have it fixed sooner. A new version of IAP SDK (4.6.0) will be released soon, and will include more traces to help us have it fixed.
I would suggest updating to 4.6.0 when it’s released to help us provide a fix, thanks to all collaborators!
We are facing this error in even the older version of TF iOS , which was working well before, but recently all of them have the same errors, of Purchasing unavailable. Is there a workaround anyone has been able to find ?