Deferred Purchases in 2022

Unity Services
,
1

Greetings Unity Developers and other IAP aficionados,

I am making this post to attempt to clarify any confusions pertaining to deferred purchases in Unity IAP.

I am working with Unity IAP v4.1.4 and only use Google Play (Android).

My scenario and question: (scroll to bottom for TLDR)

In my testing of consumables and deferred payments, I have deferred purchases working on my local device using the ‘slow test card’ process, I have SetDeferredPurchaseListener() and everything else required to get it to work resulting in ProcessPurchase spitting out a PurchaseEvent (receipt) POST payment received.
I also have ‘instant’ purchases, non-consumables, and subscriptions seemingly working as well.

While debugging the deferred purchase process, as I just mentioned, I noticed ProcessPurchase is not called until the payment is received (in testing, this would be when Google Play is notified the payment has been received).

Upon noticing this, I dug a little deeper and noticed I am only returning PurchaseProcesssingResult.Complete, but in the most recent sample Unity documentation and code, it is suggested that you return PurchaseProcessingResult.Pending for deferred purchases and how you go about doing this is by parsing the receipt given to you from ProcessPurchase, find the purchase state, and set the PurchaseProcessingResult based on the number given. ie 0 for unknown, 1 for success, 2 for pending, and possibly 4 for pending as well.
Reference: Google Play IAP Problem

I added this to my code and did more testing:
ProcessPurchase isn’t called until the purchase is complete or paid for by the user (I’ve only ever dared to test this with a test card, never on a live/real application). The receipt given was always returning a 0 purchase state, only after the payment was processed, but there was never a chance for my ProcessPurchase code to return a Pending processing result because by the time it hits that code, the payment is received and thus is complete.

I thought this was weird, so I sought out answers only to be more confused. I went and found the Unity IAP sample project which is supposed to be used for code samples for our own projects.
Last posted here on Feb 2022: Sample IAP Project

The developer of the sample project also incorporated the Pending processing result as part of the ProcessPurchase method, but upon doing the same deferred purchase testing as above, I was left with the same result: the pending processing result is never reached in the code, only the complete result is ever returned. Upon further inspection, I noticed that the code sample given for checking for pending or complete purchases, doesn’t actually check any purchase states or receipts, it’s flipped off of a seemingly arbitrary boolean which doesn’t appear to be tied to anything anymore, likely some depreciated code.

The Unity sample code given for ProcessPurchase:

8114498--1051160--upload_2022-5-9_15-39-18.png
8114498--1051160--upload_2022-5-9_15-39-18.png1083×224 12.9 KB

The Unity sample code given which looks like it was tied to a button event at one point, but now is tied to nothing and thus since this bool can’t be ‘toggled’, the code returning the Pending result is never reached:
8114498--1051163--upload_2022-5-9_15-39-42.png

So after all of this, my question is (TL;DR):
In testing of both my own and the Unity sample project given, ProcessPurchase method isn’t called until the payment is completed/paid regardless of whether the purchase is deferred or not.
So is there any need to even separate the logic for complete and pending anymore?
Should I expect this process to somehow change when running in a live production environment?
ie ProcessPurchase is executed after a deferred purchase to trigger a pending result as opposed to only being triggered after, like my testing.

I currently have my code reading receipts and if the purchase state is a 2 or 4, it will return pending result, otherwise it will return a complete result, but as stated, the pending state is never reached.
Is this the proper implementation for production?

Thank you for reading and for your consideration,
Pleebie Jeebies

1 Like
2

@Pleebie It appears that purchaseState = 0 is returned during the restore of a previously purchased item. In this case, you would return Complete from ProcessPurchase and ensure the user has been awarded the IAP product in the game. When testing deferred purchases, make sure you are testing the scenario when a user reinstalls the game, and also deletes then installs again. This will trigger a restore. Also test on a second Android device. This is when you might expect to see ProcessPurchase trigger with purchaseState 2 or 4 during restore, but they haven’t paid yet. I’ve heard many opinions on the 2 vs 4 values also, I’ll try to pin this down. Also, I’m not sure how close “Slow Credit Card with Success” matches the new deferred purchase option in behavior, as the name implies.

3

@JeffDUnity3D I appreciate the quick response and your diligence.

I was not aware of these testing scenarios, so thank you for that. I will be able to do some proper testing of deferred purchases now, as it sounds like the way I have been testing is not reliable.

Specifically, how would you go about testing deferred purchases then?
Do I still use the “slow credit card with success” option and then quickly reinstall to trigger a restore?
Is a ‘restore’ the same thing as a ‘pending purchase’?

I’m wondering specifically how you trigger the “they haven’t paid yet” portion of testing.
Do I have to be on a second device, but re-process the purchases from the first device somehow?

Sorry for the confusion and thanks again.

4

There is no specific test for deferred purchases. Please keep us posted. You can also try with the Slow Credit Card Decline option. Restore is not the same as pending. A restore applies to already paid-for products, and deferred Pending is still waiting https://docs.unity3d.com/Manual/UnityIAPRestoringTransactions.html

5

Ok, good to know.

So if I understand you correctly, Unity developers can not safely release IAP with deferred purchases to a live environment as if there is no real way to test, there is no way to tell if it is working without risking someone’s money.

In response to the “slow credit card decline” option, I’ve done some research on that as well with similar results.
In my own testing, my results are similar to what you yourself specifically mentioned in other forum posts: I get no receipt or processPurchase from the “slow decline” option and thus no purchaseState. And also have to clear any declined pending purchases with the “confirmPendingPurchase” function.
Reference: Unable to Test Google Play Slow Card Payments
Also: "ProcessPurchase" function calling declined deferred purchase from Google Play Store

I haven’t seen any further updates beyond what is mentioned in the posts I just linked.

So back to what I first said, it would appear that “slow credit success/decline” are not accurate ways of testing deferred purchases, and according to you, there is no proper way of testing deferred purchases.

So if this is the case, I will be moving on to something else as it doesn’t feel right to me to release an app (with IAP) to the public without fully testing it and knowing it works, let alone putting people’s money at risk.
Especially since I know you can’t release IAP without allowing deferred purchases, otherwise I would simply do that.

6

It’s up to Google to provide the testing platform, not Unity. They need something similar to the Slow Credit Card. That is a Google feature, not Unity. We would not want to inject a fake receipt into the purchase flow for security reasons. We are a passthrough service for the Google Billing Library API. You would experience the same testing issues if you coded IAP natively. Google is updating GPBL to v4 (and v5!) soon, so hopefully they will offer improved test options. We will incorporate their latest libraries in Unity IAP future updates as they become available. Your point is taken. Google is sending emails to developers saying they are not handling these purchases properly yet offer no way to test them.

7

Yes, I understand it is up to Google, just wanted to make sure I am not crazy and that there are in fact no testing options for deferred purchases. Thank you for clarifying. Hopefully we get some better test options soon.

As a final question:
Does this mean other developers are likely releasing apps with IAP (to Google Play) not fully tested?
Or worse yet, Unity Asset store developers selling IAP products to other developers knowing it can’t be fully tested.

I suppose IAP could be tested on a live environment, which maybe is what they did.

Anyways, thanks again. Take care!

8

We have many studios successfully handling deferred purchases now with the recommended code.

9

Ok, maybe I misunderstood what you were telling me then.

At the bottom of my original post, I was asking if I have the correct implementation to use for deferred purchases.

As long as I’m parsing receipts, or more specifically the purchaseState, and returning the proper PurchaseProcessingResult, I should be alongside those studios who successfully handle deferred purchases?

Or what is the recommended code? This is what my initial question was.
Because I noticed the Unity sample code given doesn’t appear to properly handle deferred purchases, as I’ve mentioned.

Edit:
I’ve only just found this code amongst the package manage import code for deferred purchases.
8120393--1052432--upload_2022-5-11_15-29-15.png
This code is different from the code in the IAP sample project, which is what I was initially using as the recommended code ( Sample IAP Project ).

Is it correct that the new image I just linked is the recommended code for deferred purchases?
Which I noticed doesn’t appear to be checking the purchase state (unless the IsPurchasedProductDeferred() method does that in the back)

10

@Pleebie I’m not understanding the confusion. You posted links to the code yourself and you said you are at the point of testing your code. Is this not the case? You now know how and where to check purchaseState, are you not using this recommendation? The Sample IAP project does indeed have a deferred listener wired up. It does not check purchaseState. Do you not get the deferred listener callback when doing Slow Credit Card? You “found this code”, does it work for you when testing, compared to testing purchaseState directly from the receipt? Following the link you provided, you will see Google Play IAP Problem - #8 by bardia68 for checking purchaseState. For the In App Purchasing library in Package Manager, there is the sample “Google Play Store - 04 Handling Deferred Purchases”

11

@JeffDUnity3D My confusion was assuming that all deferred purchases are pending purchases, which appears to not be the case. I do have the deferred listener working as well.

My problem is that I wanted to know what the proper way to handle pending purchases, and when to return a ‘pending’ state in the ProcessPurchase callback. Which I believe you’ve been able to help me get to the answer.

In testing, I noticed that ProcessPurchase isn’t called until the purchase is completed when attempting a deferred purchase (slow credit card), and thus always returns 0 purchaseState, which seems to match up with this post: Google Play IAP Problem - #10 by Darktemplar1

But as you’ve mentioned, this isn’t an accurate way to test ‘pending’ purchases.

From what I’ve gathered from other posts and what you’ve told me, it would appear that the solution remains to be as you’ve stated previously: Google Play IAP Problem - #13 by JeffDUnity3D

I will use this in my implementation of IAP.

Thank you for your time and wisdom. It is much appreciated.

12

As mentioned, you’ll want to test Restore with a purchase in Pending. I suspect you’ll get a ProcessPurchase call, before they actually pay.