OnPurchaseCompleted called on App Launch

Hello,

We recently enabled our game globally both for Android and iOS. Our game, of course, includes IAPs, which most of the time seem to be working as expected.

The problem we're facing is that we've seen some sort of hacking or maybe bug exploit being used by a couple of users in Android, which based on our analytics follow this flow:

User goes to the store -> Clicks on an IAP, so the IAP pop up is triggered -> User closes the app -> User relaunches app -> IAP is completed on app launch.



We have checked our script several times, we do not cache anything related to store or IAPS, so it looks like the user leaves the IAP as pending and then it is completed automatically when the IAP are initialized for some unknown reason.

This in an example of a Mexican user who did this exploit, where we can see his payments are stuck on pending status but he has received all the rewards.



To be honest we don't have much security nor are we sure how to improve it, as for now we're just using the recommended receipt validation.

What can we do about this ? We're using last Unity IAP Sdk and Unity 2020.3 LTS

 

Hello Jeff, thanks for your interest in the matter.

We tried to reproduce it but we weren't able.

SDK Version where this happened was the previous to the latest, 3.1 I think? We just updated to 3.2.1 and we're pending to launch an update, but we saw this with older version of the SDK as well

We're using Scripted IAP, do you need us to share the code?

 

Here is our manager and the button which starts the shopping process.

 

We do receive ProcessPurchase in this scenario, since we are receiving the corresponding analytic which only happens in that function.



As you see we don't have the deferred purchases enabled nor we want them enabled.

What we are really curious about, is this pattern behaviour, where users may know of some API vulnerability because, why would you even try to: Intent purchase -> Force close -> Re-open app

We don't imagine a specific scenario where our game has lead the user to behave like this. Have you not heard of this exploit before?

Either way we're comparing with the Sample project if you don't see anything weird...

Thanks!!

 

What I meant, is that we find really weird such pattern behaviour by several users like they knew how to force a fail on the API. As I said we couldn't reproduce but maybe because we have some uncontrolled step, we've also seen users trying to do this exploit but without any luck.

If I understand correctly, they could be legitimate, unhadled deferred purchases? But, if that were the case, why are all these guys following the same steps? (we've seen 3 doing this exploit and 1 trying)

To clarify when this happen, the users open the google's shop popup, then force close the app and relaunch it. that's what we've seen, doing if for every purchase.

Here we have a user trying to hack the purchase, it looks like he's trying for the purchase to be in a specific state and hence the several clicks on the purchase?

 

Thank you!! Checking if purchase comes from a button click sounds like an easy-straight forward solution...

About the receipt, any tip on what parameters we should be looking at? We already have the recommended receipt validation, so, what else?

 

We are also seeing this issue as well where Unit’s IAP framework thinks the player confirmed the Google Play purchase, but no payment was received. (No payment was verified in Google Play Console, but Unity IAP logs indicated a purchase). Note that even after, with Unity IAP's provided product.reciept - validation passes server side.

This looks to be malicious player behaviour - right after installing the game, he proceeds to perform this exploit as one of his early user event steps.

Similar to @Draikz, we see similar behaviour in our metric logs.



This happens on Android. We are using IAP version v3.1.0

 

We are selling "Gems" IAP that are consumables. After processPurchase, we validate server side and confirm the purchase via Unity's StoreController.ConfirmPendingPurchase. Like @Draikz we are not able to reproduce the conditions under which it had occurred to reproduce the behaviour.

My understanding is that processPurchase would also be triggered upon Unity IAP initialization if a previous purchase payment process was completed but the app is not notified (Google credit card payment dialog confirms payment, but the app is restarted before anything else happens) - please correct me if i'm wrong here.

Thus, from our logs, the player InitiatePurchase, but the restarts. Upon restart, processPurchase is triggered with the receipt containing purchaseState = 4. To which we then use Playfab to verify (server-side verification).

One interesting thing is that the purchase state on these transactions are "4".
That seems to correspond to this thread where an exploit is mentioned in the case of deferred purchases with Google Billing Library v3:

"It appears that some users may be exploiting a new feature offered by Google Billing v3 where they indeed choose a deferred payment method. If you are using server site validation you will need to accommodate purchaseState = 2 (or 4)."

Perhaps they sound related?

 

Can you please point to us Unity's documentation and guidance on what to do when purchaseState is 4 and deferred purchases? This sounds like a specific behaviour to Android and we want to ensure we aren't missing anything.

It does looks like we are seeing the same behaviour as some of the users on that thread. So it sounds like irregardless adding a deferred listener is required to bypass the exploit?

@mrm83 where he mentions:
"Our case:
no deferred listener, ProcessPurchase gets called for these unpaid purchases and it gets validated. FREE IAP."

@roointan where he mentions:
"We see purchases in Pending payment status in Google Play console, and they get cancelled automatically after some time.
But they are accepted as complete purchases in the game."

 

Thanks @JeffDUnity3D, can you provide an example of how users defer the payment until later at an approved physical store? How can we test this case?