We are trying to test IAPs in Windows Universal Platform, but despite all our apps and add-ons being “In Store” for several days they still do not work. We’re using the Unity Purchasing system and it doesn’t seem to initialize. No callbacks are called, neither OnInitialized nor OnInitializeFailed.
We found a few similar reports from Unity users that mention that it started working after a few days for them, and that it usually takes 24 to 48h for the IAPs to start working on Windows Store after being set to “In Store”, so this could be normal, but in our case it has been significantly longer and the IAPs still seem to not be available. (source: [Solved] Initialization on UWP )
The console output that we’re getting when testing the app on our local machine through Visual Studio, is the following:
UnityIAPWin8:Begin PollForProducts() persistent = True, delay = 0, productsOnly = False
and after some time
UnityIAPWin8:Begin PollForProducts() persistent = True, delay = 10000, productsOnly = False
UnityIAPWin8:Begin PollForProducts() persistent = True, delay = 20000, productsOnly = False
This also matches some of the reports from Unity users, mentioned above.
TL;DR: The IAP system on UWP doesn’t initialize, despite doing all the correct steps, including having the app published in the store. Any insight is much appreciated
Can you provide the full logs from your testing? What device/platform are you testing on? Also, please show the purchasing code that you are using. There is a sample project here Sample IAP Project
We’re testing on a desktop computer running Windows 10, through Visual Studio. This is the code we’re using to initialize the IAP system:
// Initialize can be called multiple times (for example over startup or later if the valid purchases could have changed)
public static void Initialize()
{
var packIds = new HashSet<string>();
// HACK: adding packs manually because Unity Purchasing cannot be initialized without everything, or it risks losing purchases
packIds.Add("dlc1");
packIds.Add("dlc2");
packIds.Add("dlc3");
packIds.UnionWith(MusicDlcManager.GetPackList());
Initialize(packIds);
}
public static void Initialize(HashSet<string> purchaseIds)
{
ConfigurationBuilder builder = ConfigurationBuilder.Instance(StandardPurchasingModule.Instance());
foreach (string name in purchaseIds) {
builder.AddProduct(IdFor(name), ProductType.NonConsumable);
}
builder.AddProduct(IdFor("full_game"), ProductType.NonConsumable);
UnityPurchasing.Initialize(instance, builder);
}
public static string IdFor(string id)
{
return "our_id_prefix" + id;
}
After Initialize being called, we should be getting either the of these events:
public void OnInitialized(IStoreController controller, IExtensionProvider extensions)
or
public void OnInitializeFailed(InitializationFailureReason error)
But we’re getting neither. Internet access is working, since we are able to access our server and DLC store without issues.
Full logs uploaded as a .txt file to avoid spamming the thread.
The code we’re using seems extremely similar to the IAP sample project. In any case, I’m not sure what testing with that project would accomplish since we need the app to be submitted and published in the Windows store for IAPs to work, according to Microsoft’s own documentation: “You have created an app submission in the Windows Dev Center dashboard and this app is published in the Store. You can optionally configure the app so it is not discoverable in the Store while you test it.”
I guess we could always test using “builder.Configure().useMockBillingSystem = true;” but we’ve already done that in our own app and it worked without issues. However, the real IAPs don’t
You have two Initialize methods which is unusual, I was hoping you could compare to the sample project which does not. And in fact, you are saying that Initialize does not look to be happening. Can you provide the full device logs during app launch? Where do you call Initialize, in a Start or Awake function?
The second Initialize method is only called by the first one, it is simply for convenience/organization reasons, it should actually be private, not public, that’s an oversight on my part.
The .txt file I attached in my first reply are the full device logs during app launch. We are calling IAP.Initialize(); in the Start method of a script that exists in the first scene of the game.
At this time I’m going to the guess the problem is actually on Microsoft’s side. I have since tested the app using both of their native APIs without success with either.
@JeffDUnity3D
Update: Apparently, all the problems described in the previous post only happen on my machine. After testing on two other computers, everything works just fine (this is using the Windows native API to access the In-App Purchases).
However, using Unity’s IAP Plugin, it still fails to initialize on all machines we have tested until now.
This leads me to believe that the problem lies somewhere in Unity’s IAP Plugin, specifically where it deals with IAPs on the UWP platform. I’ll try to investigate further and update if I find any more details.
Exception thrown at 0x00007FFDA166A388 in unity2017_IAP.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x000000E9257FD0B0.
Exception thrown at 0x00007FFDA166A388 in unity2017_IAP.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x000000E9257FB940.
[9.192999 / 29.821591] - OnWindowActivated event - Deactivated.
The thread 0x3e8 has exited with code 0 (0x0).
The thread 0x3434 has exited with code 0 (0x0).
info:LoadListingInformationAsync() invoked. [Windows::ApplicationModel::Store::CurrentAppFactory::LoadListingInformationAsync]
Exception thrown at 0x00007FFDA166A388 in unity2017_IAP.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x000000E924EFCF70.
Exception thrown at 0x00007FFDA166A388 in unity2017_IAP.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x000000E924EFB800.
The thread 0x4720 has exited with code 0 (0x0).
The thread 0x376c has exited with code 0 (0x0).
info:LoadListingInformationAsync() invoked. [Windows::ApplicationModel::Store::CurrentAppFactory::LoadListingInformationAsync]
Exception thrown at 0x00007FFDA166A388 in unity2017_IAP.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x000000E924FFD3D0.
Exception thrown at 0x00007FFDA166A388 in unity2017_IAP.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x000000E924FFBC60.
In my case it only fails when I’m signed out of the Microsoft Store. So that might be the reason why @Kryzarel reports it working on some machines and failing on others.
IN my case I Signed in always and I config UWP + IL2CPP + .Net 4.6 + IAP 1.20.1 Failed to initialize
by the way , Kryzarel’s IAP 1.19 ? if you updata to 1.20.1 , it be fine?
It is crazy how many things go wrong with unity when trying to build for windows.
The inputfield doesn’t work correctly, which is only fixed in 2019.1, I have this issue too which is still not fixed AFAIK.
Crazy, every new version of unity some stuff gets fixed and some other stuff gets broken again.
Will have to wait until this is fixed before I can publish I guess…
I’m experiencing the same issue. I have tried multiple Unity versions (2018.3.5f1, 2018.3.6f1, 2019.1.0b3 and 2019.1.0b4) and Unity IAP versions 1.16.0, 1.17.0, 1.18.0, 1.20.0 and 1.20.1. Using .NET scripting doesn’t work, either. The sample project creates the following log seen in attachment 1, whether the project is published in the store or not.
As you can see, OnInitialized or OnInitializeFailed are not called. The same project produces the log seen in attachment 2 on Android.
The initialization fails for the sample project, as it should. The UWP issue does not seem to be present here. Using builder.Configure<IMicrosoftConfiguration>().useMockBillingSystem = true does allow the IAP to initialize. Using this in production occasionally logs this as well but nothing happens anyway:
UnityIAPWin8:Building full product list with existing purchases
Building the sample project with Unity 2019.1.0b4 doesn’t work at all, building it causes the errors seen in attachment 3.
@TeemuTee It’s generally preferred to attach logs as an attachment, not inline that requires scrolling. At any rate, we are aware of this issue, we believe a possible change on the Windows store side but not confirmed. There are no immediate plans to address this behavior, but is being discussed.
