We have been receiving issues with customers who have been making purchases on GooglePlay. Having investigated this we believe that this is an issue with how we are handling pending payments for cards that take time to process. With the release of the Google Billing 2 api, there is now support for testing these slow cards but we have been unable to get this to work with the Unity IAP plugin as the “Slow Test Card” option does not appear when attempting to make a purchase. We created a test Android Studio app to prove that we had everything set up correctly on the GooglePlay side and the option showed up correctly there so we believe that this is an issue with Unity IAP.
We have updated Unity IAP to the latest version (1.23 as of writing) but can still not see the “Slow Test Card” option when testing a purchase. Does the Unity IAP plugin not use the latest Google Billing 2 api?
Any help or assistance would be greatly appreciated as this is affecting real customers and we would like to resolve this ASAP but are unable to actually test the issue at present.
Yeah, we’re the same. We only get two options when testing purchases via Google Play. Neither of them are the slow test card. We’ve had reports of users not getting their purchases and am now thinking it might be the same thing.
I see a number of purchases in the Google Play Console that sit in a “Pending purchase” state for minutes before changing to “Chargeable”.
We are just a pass through for the respective stores, we do not introduce any additional processing or delays. But we believe we have identified a separate issue with users receiving PurchaseFailed but still being charged, this should be fixed in the next release hopefully in a few weeks.
I appreciate that the Unity IAP plugin is a wrapper around the various stores but is there any documentation on the versions of those store APIs in Unity IAP 1.23 or the new version that will come out? One of the theories that we have for why the Test Card might not be showing when making a test purchase is that the Unity IAP plugin could be using a version of the Google Billing API that is older than v2, but we haven’t seen any documentation that can tell us what version is included. We can see a google billing aar inside the Plugins folder but are unable to verify the version of this.
The other theory that we have is that, as per the Android Docs, enablePendingPurchases needs to be set to enable pending purchase functionality. On our AndroidStudio demo we have set this via the BillingClient.Builder class but there does not seem to be an equivalent in Unity’s ConfigurationBuilder, or any similar looking functionality in the IGooglePlayConfiguration interface. Does Unity enable this functionality by default or provide some way to enable us to configure that to be enabled?
@TJClifton_StickSports Sorry, I don’t quite follow. Do you mean the test card that testers are presented with so they aren’t actually charged, or a feature that allows/enforces a slow response in the purchase transaction? Test cards work just fine, you need to make sure you browse to the Opt-In test URL from a browser on the actual device, it will prompt you (on each device) to join the test program. It will confirm that you are now a tester, and will prompt you to download from Google Play. These steps are important, you can’t simply just install the game directly on your phone via USB, you need to opt-in first. Subsequently a test card pop-up will be presented on each purchase. You configure your list of testers on the Google Play Developer Dashboard. Can you show a screenshot of the option that provides slow response times?
@JeffDUnity3D I’m not talking about standard Test Cards, those work fine. We have had those implemented for months and they work as you would expect.
As I said, I am talking about what Google refers to as a “Slow Test Card”. So as an illustration, in a demo project made with Android Studio that uses the Google Billing API v2, you can see that when we make a purchase we see 4 total options - the 2 normal test card accept/declines and 2 more accept/decline options for Slow Test Card.
However with the latest version of the Unity IAP plugin (we upgraded to 1.23.1 today but that hasn’t resolved the issue) when we test the product we see only the standard 2 options as shown below.
As I mentioned before, we believe that this could be caused by Unity using a version of Google Billing that is older than v2 when this functionality was introduced. But Version 2 was introduced in May 2019 so if this is the case I’d be surprised and disappointed that the Unity IAP is using such an old version of Google Billing.
Can you confirm the version that is used by Unity IAP as I can’t find anywhere in the Untiy release notes what version the Unity IAP is using. If Unity is using v2 of Google Billing are there other steps that are required to enable this option? As you can see from the attached options with the same options set on GooglePlay we see the Slow Test Card option in a demo with GoogleBilling v2 but not with Unity IAP 1.23.1 so it looks to me like an issue/lacking feature on Unity’s side.
Without these options it is impossible to test purchases that end up in a pending state that are made with slow credit cards and this issue is affecting a large number of our users. Without being able to test this with the options Google provides it is impossible for us to test this issue and resolve it.
Got it. The issue that you are seeing is not with slow credit cards. It’s with the IAP plugin not properly consuming the purchase in some situations. A PurchaseFailed is received but the user is still charged. Please test with 1.23.1 which was just released. We are working directly with Google to implement their newest billing API, and should be included in an upcoming release.
You mentioned subscriptions and the Google slow credit card feature is not related to subscriptions. The slow credit card feature should be available iwhen we move to the updated Google billing library, hopefully later this year. Separately, there is information on subscription handling here https://discussions.unity.com/t/702595
Slow credit card testing feature is supported and working now. The latest IAP 2.2.5 includes the Google v3 Billing library. We don’t seem to receive the failed callback from Google however, only the ProcessPurchase after a few minutes.
Has this been fixed? We still see the same issue occur in 3.1.0 where the “Slow Test Card, declines after a few minutes” option doesn’t trigger any of the IStoreListener methods.
Is there a way to identify Pending status for “Slow Test Card, declines after a few minutes” option and show a proper message to the user to wait confirmation?
It seems that I should decide myself if a purchase is Pending or Complete returning one of these values in my IStoreListener.ProcessPurchase implementation, but I need reliable data from the Store to backup this decision and this data doesn’t seem to be available through Unity IAP.
What I want to achieve is this:
User buys a non-consumable item with “Slow Test Card, declines after a few minutes” option;
The app shows a message saying the purchase is pending (based on reliable data from purchasing process);
The app can check the purchase status of the item at any time to change its Buy Button label to show “Pending” while the purchase isn’t cancelled yet and “Buy” again when it finally gets cancelled.
Steps 2 and 3 don’t seem to be possible using Unity IAP. I tried to use the receipt payload data returned for Google Play, but the fields don’t seem to be reliable either.
The value for Payload.json.purchaseState is UNSPECIFIED_STATE for successfully purchased items instead of PURCHASED. When using the “Slow Test Card, declines after a few minutes” option, the value for Payload.json.purchaseState is 4, which isn’t even a possible value in Google’s documentation.
@JeffDUnity3D This seems be an issue, if I not missing something. How can I handle this Pending → Cancelled scenario and properly inform the user about what it’s happening (and avoid making the user angry due to the lack of feedback)?
You’ll want to use the Deferred Listener as demonstrated in the Sample IAP Project v2. purchaseState = 4 is a deferred purchase and you’ll want to return Pending until the user finally pays (purchaseState = 1). Deferred purchase support is required by Google. Here is the Sample IAP Project https://discussions.unity.com/t/700293/3
Thanks for the reply, Jeff. But it seems there’s actually an issue here.
The current flow of my app is this:
User buys a non-consumable product with Slow Test Card, declines after a few minutes option;
The Google Play UI immediately shows that the purchase was successful (although it’s pending) and the IStoreListener.ProcessPurchase is not triggered at this point;
The app somehow needs to say to the user that the purchase is pending before IStoreListener.ProcessPurchase gets triggered, but that’s not possible at this point.
After Step 1, a receipt is set for the pending product in IStoreController.products, I should be able to use that in Step 3 to verify the purchase status and show it to the user, but the purchaseState for that receipt is incorrect.
When I buy a product with the Test card, always approves option, purchaseState for that product is set to 0 (not 1, as expected according to Google’s documentation). When I buy a product with the Slow Test Card, declines after a few minutes option, purchaseState for that product is also set to0 in IStoreController.products. So I can’t tell if a product is Pending or Purchased because Unity IAP wrongly set the same state for different situations (and purchaseState 0 isn’t PENDING or PURCHASED according to Google, it’s UNSPECIFIED_STATE (!) ). I never get purchaseState != 0 in IStoreListener.ProcessPurchase at any point.
I only get purchaseState = 4 in purchaseEvent when IStoreListener.ProcessPurchase finally gets triggered after using the Slow Test Card, declines after a few minutes option to buy the product. I think using the Deferred Listener, as you suggested, won’t solve the problem of the purchaseState being incorrect in IStoreController.products until the purchase is actually processed.
This is an issue, Unity IAP should provide correct purchaseState in accordance to Google’s documentation. Should I submit a bug report?
