Google payments are being automatically refunded.

Hi.
I added Google subscription payment using Unity IAP, codelssIAP.
72 hours after the user makes the subscription payment, it is automatically refunded.
I tried with a real personal account, but the subscription was automatically refunded even though I did not cancel.
Is it a problem with Unity IAP?
This problem did not occur when using Unity IAP version 1.18.0.
The problem occurs after updating to version 2.2.5.
I am using Unity IAP version 2.2.5 and Unity 2019.4.11f1 version and In-app purchasing package version 2.2.1.

 

How do you know it is refunded, please share a screenshot.

 

@JeffDUnity3D
The screenshot is a record of two other users' subscription orders.
I checked it in the Google order history.
Thanks.

 

This is not an issue that we are aware of. Can you share the device logs when this happens? https://forum.unity.com/threads/sample-iap-project.529555/

 

As a result of contacting Google, I received the following answer.

If you use Google Play Billing Library 2.0 or later, you will automatically receive a refund if you do not acknowledge the purchase within 3 days and Google Play will cancel the purchase. Renewal of a subscription product does not require confirmation of purchase, but it is confirmed that all initial subscription order orders require purchase confirmation.

Therefore, please check whether acknowledgePurchase() is properly implemented in your app. For more information, please refer to the following Android developer documentation.
https://developer.android.com/google/play/billing/billing_library_overview#acknowledge


What method should be used in Unity IAP for this?

 

We should be doing this already, you can see the acknowledge flag in the receipt. In your testing, did you wait 3 days, and then see the refund?

 

I made a purchase from an app that has already been distributed. Purchases were made in the same way as regular users in the actual distributed app. It was confirmed that the refund was automatically issued after 3 days.
You can see it in the screenshot from this thread.

In addition, when a one-month subscription test purchase is made with a test account, the results appear within 5 minutes, and an automatic refund is also provided.

It was said that the acknowledge flag could be checked, so I checked the log by test payment. It turns out false. The test payment details are shown in the Google order history.
What is the procedure for the acknowledge flag?

 

Are you checking the Consume Purchase flag on the IAP Button properties in the Inspector? We may have an issue but need to gather as much information as possible, we've heard previously of this same issue https://forum.unity.com/threads/subscription-acknowledged-false.1030417/

 

I have the same problem.
I upgraded the IAP version to 2.2.7, but it still seems to happen.

Consumable products are handled normally.
However, non-consumable products are automatically refunded after 72 hours.

Can you share a solution for this?

 

Not entirely sure if this is related, since we're only using consumable products, but we've had similar issues nonetheless. We had thousands of dollars worth cancelled IAPs just last weekend on Android. There seems to be some kind of exploit that forces the purchases to cancel, not sure if it's about the application, faulty payment method or something else. A user reported that they could abuse the Family Link to produce this: The purchase requires permission from a guardian but closing the application at the right moment will trigger the purchase anyway.

We're using server backend to verify the receipts and this was happening with IAP version 2.2.6. In the Google Play console, these purchases have an "Order received" event, then "The order is being canceled" after a minute or so and "The order could not be completed and was canceled" five minutes later. The Family Link ones seem to have a wait time of over 24 hours before the cancel actually happens. The thing is, the Google API at our backend accepts the initial receipt before the cancel and the user gets their product. We have no idea how the users can cancel the purchases like this. Note that these are not refunds. We can see that the IAP plugin is sending errors with of type "Unknown" as well.

We suspected that this must be an issue in Google's end, because the faulty orders were accepted by their API and they're the ones creating the orders, right? But we noticed that these started happening after we updated the plugin, so we blindly reverted the version to 2.1.1 (again). The issue was fixed and now we see the following events in the Play Console: "Order received", then immediately "There was an issue charging the customer’s payment method" and after five minutes "This order could not be completed and was canceled". The users do not get their product this time.

This makes us to wonder how the plugin can affect the validity of the purchases or payment methods.

 

The Refund issue should be fixed in Unity IAP 2.2.6 and above, and In App Purchasing library 2.2.2 in Package Manager . Previous purchases will still have the issue, but new purchases (both consumable and non-consumable) should not see the auto-refund behavior.

 

I was using Unity IAP 2.2.7, and App Purchasing library 2.2.1 in Package Manager.
As it was an urgent problem, I downgraded to Unity IAP 2.2.3 version, which worked fine, and applied the patch.
As you said, I'll try again after upgrading the App Purchasing library to version 2.2.2 in the next app update.

 

I double-checked, and we were using versions 2.2.6 and 2.2.2 in our problematic live build. Since we could not reproduce the problem ourselves and it was only exploited by users, I can't provide any more details about our issue. We only know that reverting to 2.1.1 In App Purchasing library prevented these approved cancels from happening. I guess we'll have to stick to the old version for as long as possible.

 

No, you'll want to use IAP 2.2.6 or 2.2.7 to avoid the issue. Keep in mind that it doesn't address purchases made with previous versions. If you can't reproduce on 2.2.6, that means it's fixed for you too.

 

What I'm saying is that the issue started after updating to 2.2.6 from 2.1.1. We had to make a hotfix and revert back to 2.1.1, and this seems to have prevented the exploit/authentication issues. We can't reproduce the issue in 2.2.6, but only because we don't know how the exploiters do it. But we can see that Play Store or our backend aren't accepting these exploit attempts anymore with 2.1.1. The plugin version is the only difference here. So no, we won't be using any version past 2.1.1 for now. We haven't tried 2.2.7 in live environment and won't dare to test it without knowing any more details, either.

 

Its not an exploit, it was a bug in IAP. We were not properly setting the Acknowledge flag prior to 2.2.6 and purchased products were refunded after 3 days by the store.

 

Sorry about the confusion and posting to an unrelated thread, but our issue had nothing to do with subscriptions or the 3 day wait, the purchases were cancelled immediately by the player or possibly by some store automation later. Please see my earlier post: https://forum.unity.com/threads/goo...-automatically-refunded.1033057/#post-6842231

Again, we experienced this issue with version 2.2.6.

 

Got it. And "thousands of dollars"? From a handful (or a single) malicious user? If multiple users, that would imply more of a system issue, and not an exploit. And your mention of it being related to IAP version is indeed concerning, sorry I missed the context of your earlier message. I doubt that malicious users would suddenly and collectively identify a flaw in an app update that uses a new version of IAP. Again would imply a system issue. I will definitely keep an eye out for similar reports, so far you are the only one. It might make sense to open a new thread if you continue to see this issue so other users looking for similar info can find it

 

I would say that there were about a dozen users who were doing this and about seven who seemed to make these type of purchases almost non-stop during specific hours (they were Indonesian). These purchases got cancelled very quickly after receiving the consumable (usually a minute or less). A few others got cancelled at around 26 hours after the purchase and we suspect these have to do with the Family Link based on feedback from a user who contacted our support.

Could it be that the changes in Google Play Billing Library 3 are causing this, such as the differences in the transaction identifier/orderId behavior? It's hard to tell exactly which party is rejecting the faulty payment method when using IAP 2.1.1.

Comparing new and old receipts, the old ones don't have things like acknowledgement flag. I noticed that it's false for both valid an fraudulent purchases (although it is possible that it has changed after saving this data). Purchase state is 0 for the valid purchase and 4 for the invalid one, I don't know what these should represent. There are crucial changes to purchase consumption and acknowledgement in BL3: What is the relationship with Unity IAP and our backend here? Does IAP consume/acknowledge the purchases? It seems like the backend should actually consume them manually, but how can we be sure that the purchase was valid from Unity IAP side?

 

I would not want to guess at the cause. You will want to use Receipt Validation. You can use PlayFab for ChilliConnect for example for server side validation or use this one (if you are not already), And non-stop purchases? That sounds like fraud. But a fraudster would not be contacting you. It could be an issue with an Indonesian bank process, we would have no control. https://docs.unity3d.com/Manual/UnityIAPValidatingReceipts.html If you can provide specific steps to reproduce, we could look into it.

 

The fraudster hasn't been contacting us, but we can see from Play Store console that these purchases are coming from the same users, and we can use our backend logs to verify that these are not normal user actions. The user who contacted about Family Link was different: There a child had been able to bypass the restrictions and got the items without a proper validation.

It's apparently not a bank issue, since the fraudsters couldn't perform the cancels in the same way after we reverted back to IAP 2.1.1: They are rejected immediately now.

We have been using Google's Android Publisher API (currently v3) for Android IAP verification in live environment for this project for over four years and it has successfully identified any faulty receipts, duplicates etc. without any issues. These issues have only been there with the IAP plugin that's targeted at Billing Library 3. The logic is quite close to this: https://stackoverflow.com/a/34005001 . I realize that the details of remote validation isn't Unity's concern, but updating the plugin breaks the validation in some way for us, and we aren't sure why. Since we have no way of knowing how Unity IAP exactly handles consumption, acknowledgement etc. I'll just repeat what I asked earlier:

"Comparing new and old receipts, the old ones don't have things like acknowledgement flag. I noticed that it's false for both valid an fraudulent purchases (although it is possible that it has changed after saving this data). Purchase state is 0 for the valid purchase and 4 for the invalid one, I don't know what these should represent. There are crucial changes to purchase consumption and acknowledgement in BL3: What is the relationship with Unity IAP and our backend here? Does IAP consume/acknowledge the purchases? It seems like the backend should actually consume them manually, but how can we be sure that the purchase was valid from Unity IAP side?"
​

I understand that this may be out of scope for this forum, since it has to do with specific Billing Library details, but I can't find any information about this. The project for the remote validation in the link you provided hasn't been updated in years, so it can't be suitable for BL3 anyway.

 

So you are not using receipt validation? And relationship between IAP and your backend? What backend are you using? But a thought comes to mind. Purchase state = 4 I believe is mapped to 2 (Pending) in the Google API. I believe these are purchases that are now allowed with v3 of the Google Billing library that allow the user to defer the purchase in-game, and then pay later with cash at a physical location that is Google approved. If they don't pay in time (3 days?), the transaction is cancelled.

 

We are using validation via Google's Android Publisher API as mentioned. We're sending the result of the purchase from Unity IAP to the server, which then fetches the order from Google using the transaction ID and other data. This works with the old plugin: Invalid purchases will return an error code indicating the issue with the purchase. Judging by all these issues, I believe we need more data now. Our backend is like this: We're running live game servers 24/7 and the server the player happens to be on will request the purchase data from Google and validates the IAPs.

What I'm interested in is who's responsible for setting the acknowledgement flag and consuming the IAP? We're sending the receipt for validation and returning pending state from the IAP plugin's ProcessPurchase and when the server has fulfilled the order, we confirm the purchase with Unity IAP. The plugin must mark the items as consumed at this point, right? We aren't explicitly sending any consume requests to Google and if no one did that, shouldn't the IAPs be cancelled/refunded after a few days? Maybe we could use the acknowledgement flag when validating the purchase, if ProcessPurchase sets that from the plugin call? That's just a guess, because I'm not entirely sure what the acknowledgement flag even is.

Thank you for clarifying the purchase state! We've had issues with Play Store gift card purchases and such in the past and I would not be surprised if these players are using this new payment method for fraudulent purposes. This might be the key to reproducing the issue. These users could cancel the purchases immediately afterwards, but I wouldn't be surprised if there's an easy way to do so with these payment methods.

 

Yes, we consume the purchase via the Google API

 

@TeemuTee We believe we have found the issue. 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). You may also want to implement a deferred purchase listener so you know when these transactions are made. We believe the exploit is that users close the app while you are waiting for the ProcessPurchase that doesn't arrive right away, and is why you would want to use the deferred listener, to drop back to your game UI right away. You can place the following code in OnInitialized:

Code (CSharp):

1. m_GoogleExtensions?.SetDeferredPurchaseListener(OnPurchaseDeferred);

Then I have:

Code (CSharp):

1. public void OnPurchaseDeferred(Product product)
2. {
3.  
4.      MyDebug("Deferred product " + product.definition.id.ToString());
5.  
6. }

 

Thank you for the info! Just to clarify: 2 is pending and 1 is purchased for Google API and 4 is pending for Unity IAP, right? I guess we'll have to block all pending IAPs if we're going to use the new version for now.

 

@TeemuTee it's my understanding that 2 and 4 are both pending. Why would you block these? You would lose out on legitimate sales. You would want to implement the deferred listener.

 

Ok, so what exactly should happen if the purchase is pending? Do not give the purchase? What happens when the person actually pays at the physical location? How does Unity handle the "paid at physical location" event?

Also, for purchase state, what is the the difference between 2 and 4? What is difference between google pending and unity pending?

Our cancelled pending purchases have a purchasestate of 1, 1 means purchased. Purchased but cancelled and we received no payment? How to handle purchase state of 1?

 

ProcessPurchase will be triggered after they pay.

 

If SetDeferredPurchaseListener is set, is ProcessPurchase still called?

 

Eventually, yes. Like 2 days later perhaps.

 

https://developer.android.com/google/play/billing/unity
The sample shows it being enabled explicity

Code (CSharp):

1. // Enable deferred purchases
2. configurationBuilder.Configure<Google.Play.Billing.IGooglePlayConfiguration>()
3.     .EnableDeferredPurchase();

Our app does not have it enabled, so shouldn't deferred payments not trigger ProcessPurchase? Or rather, users shouldnt even be able to make deferred payments in our app right?

 

You will want to add the deferred listener so you know that the user has made a delayed purchase and drop back to your game UI. Later, you'll receive the ProcessPurchase. The only purpose of the deferred listener is to let you the developer know that the ProcessPurchase will be delayed. It serves no other function. If you don't use the listener, you'll still (eventually) receive the ProcessPurchase.

 

The problem is the validator from ProcessPurchase validates these pending purchases as VALID resulting in fake purchases for us.

Our case:
no deferred listener, ProcessPurchase gets called for these unpaid purchases and it gets validated. FREE IAP.

New case:
add deferred listener, ProcessPurchase will be called eventually as you said, and i assume the validator will still validate the purchase as the deferred listener servers no other function except to delay the ProcessPurchase call?

So what is the point of adding the deferred listener when ProcessPurchase will be called regardless and the validator validating unpaid payments?

What am i missing?

 

Some developers pop up a Please Wait dialog in the game while waiting for the ProcessPurchase. It would be a long wait if ProcessPurchase is called 2 days later. As mentioned, the listener will let you know to close this dialog or not show it. ProcessPurchase should not be called for "unpaid purchases". It's only called in this case when the use finally goes into a physical location and pays in person. Google gives them 3 days to do so. In "Our case" above, when are you seeing ProcessPurchase, is it right away (seconds)? Or some time later. If right away, then you are likely seeing a different issue.

 

We are seeing both.

These pending purchases are being validated as fake in some cases and real in some cases.

It is also called multiple times for the same transaction, few hours apart.

 

We would need steps to reproduce. Your back end needs to accommodate purchaseState = 2 and 4. Please use the term deferred instead of pending to remove ambiguity. Pending purchases are a separate flow (ProcessPurchase can return Pending vs Complete, but this has nothing to do with deferred purchases)

 

Just did a deferred test and I can tell you it is bugged.

The flawless scenario
Made a deferred payment and ProcessPurchase not called. Great, no problem here.
Waited few minutes and purchase came in and item given.

The bugged scenario
Made a deferred payment and ProcessPurchase not called. Great, no problem here.
Killed the app, relaunch the app.
ProcessPurchase called, purchase state is 4 from receipt, did nothing, returned pending.
waited, waited, and waited even more.. ProcessPurchase not called again and purchase never given to user.
Google play shows purchase completed.

The bugged scenario 2
Made a deferred payment and ProcessPurchase not called. Great, no problem here.
Killed the app, relaunch the app.
ProcessPurchase called, purchase state is 4 from receipt, did nothing, returned completed.
waited, waited, and waited even more.. ProcessPurchase not called again and purchase never given to user.
Google play shows purchase completed.

returning both pending and completed results in no item for user.

Not sure how checking for 2/4 helps as ProcessPurchase doesn't get called again when it becomes 0.

 

How are you initiating and then paying for the deferred payment in your testing? This isn't the "Slow Credit Card" option when testing a purchase on Android (is my understanding). I personally have not been able to test a deferred payment, the option is not available for me. Can you share a device screenshot? Yes, the exploit being discussed here is when you kill the app during a transaction. When you say "kill your app", you mean just normally exit the game per usual and start a new game session (and not when a purchase dialog is up, for example) And you mentioned "waited and waited and waited", you know you are waiting for the user to go into a physical store and make the payment. They have 3 days to do so. If they don't, apparently Google issues the refund.

 

Yes, I am using the "Slow test card. Approves after a few minutes" option.

"Slow Test" approves after a few minutes. The purchase should be completed after a few minutes for test method. So if a few minutes past and nothing comes in to ProcessPurchase, then that means nothing is going to happen. The 1 minute between making a purchase and purchase completing is equivalent to the "3 days" to make a physical payment.

I've retested my 3 test cases using a dev build and here are the results (previous test used production build and results were based on our server logs and not device log which was wrong)

The flawless scenario
Made a deferred payment and ProcessPurchase not called. Great, no problem here.
Waited few minutes and purchase came in and item given.

The good scenario
Made a deferred payment and ProcessPurchase not called. Great, no problem here.
Killed the app, relaunch the app.
ProcessPurchase called, purchase state is 4 from receipt, did nothing, returned pending.
wait few minutes and ProcessPurchase called again and purchasestate 0 given, grant item, return completed.

The bugged scenario
Made a deferred payment and ProcessPurchase not called. Great, no problem here.
Killed the app, relaunch the app.
ProcessPurchase called, purchase state is 4 from receipt, did nothing, returned completed.
wait few minutes and ProcessPurchase called again and was given "Already recorded transaction", item not granted

so returning completed for 4 is WRONG. Pending needs to be returned.
Returning PENDING vs COMPLETED does matter for deferred purchase.

Also, please confirm what purchaseState 2 vs 4 actually mean. According to Google, there is no 4. But the purchaseState returned from the receipt is 4 and not 2? It is safe to check for 4 and return pending instead of checking both 2 and 4?

Also, need to set deferred event.. otherwise there will be error:

Code (CSharp):

1. 03-01 15:31:24.141 29501 29501 E Unity   : NullReferenceException: Object reference not set to an instance of an object
2. 03-01 15:31:24.141 29501 29501 E Unity   :   at UnityEngine.Purchasing.GooglePlayStoreExtensions.NotifyDeferredPurchase (System.String productId, System.String transactionId) [0x0001f] in <b3a8c8d5217341a69444d34cb072db42>:0
3. 03-01 15:31:24.141 29501 29501 E Unity   :   at UnityEngine.Purchasing.GooglePlayPurchaseCallback.NotifyDeferredPurchase (System.String sku, System.String purchaseToken) [0x0000b] in <b3a8c8d5217341a69444d34cb072db42>:0
4. 03-01 15:31:24.141 29501 29501 E Unity   :   at UnityEngine.Purchasing.GooglePurchaseUpdatedListener.OnPurchaseOk (UnityEngine.Purchasing.Models.GooglePurchase googlePurchase) [0x00046] in <b3a8c8d5217341a69444d34cb072db42>:0
5. 03-01 15:31:24.141 29501 29501 E Unity   :   at UnityEngine.Purchasing.GooglePurchaseUpdatedListener.ApplyOnPurchases (UnityEngine.AndroidJavaObject purchasesList, System.Action`1[T] action) [0x0004a] in <b3a8c8d5217341a69444d34cb072db42>:0
6. 03-01 15:31:24.141 29501 29501 E Unity   :   at UnityEngine.Purchasing.GooglePurchaseUpdatedListener.onPurchasesUpdated (UnityEngine.AndroidJavaObject billingResult, UnityEngine.AndroidJavaObject purchasesList) [0x00021] in <b3a8c8d5217341a69444

 

Got it, good information. So if you receive purchaseState 2 or 4, then return Pending from ProcessPurchase, noted.

 

Please confirm what purchaseState 2 vs 4 actually mean. According to Google, there is no 4. But the purchaseState returned from the receipt is 4 and not 2?

It is safe to check for 4 and return pending instead of checking both 2 and 4?
I have not seen 2 during these tests..

 

4 looks to be mapped to 2 in the Google library, so they appear to be equivalent. And I stand corrected, the Slow Credit Card option does indeed trigger the deferred listener so is a valid test. I never receive the OnPurchaseFailed for Slow Credit Card with Failure" as others have mentioned, FYI.

 

We are experiencing something similar with version 2.2.6 of the IAP plugin.
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.
Is this the solution I need to use to prevent that?
(We do not use server-side validation)

 

Please provide steps to reproduce. If they are Pending and you are always returning Complete from ProcessPurchase, this would imply a deferred purchase where users can initiate the purchase in-game, then pay later in person at a physical store. They have 3 days to do so. You would likely want to implement a deferred listener

 

Is there a fix to this? After we updated the Unity IAP all our trial subscriptions gets cancelled after 3 days, and "refunded" 0.00$.. Even though nobody has done anything to cancel it and we promise people 7 days of free subscription. Before the IAP update it worked flawlessly...
I am running Unity IAP 2.2.7 and Unity 2018.4.31f1

 

Please see previous replies, this is expected. These look to be deferred purchases, please confirm. You would be seeing purchaseState = 2 or 4 in the receipt. Deferred purchases are a new purchase method now offered by Google where the user can purchase in-game then pay later in person at a Google-approved physical store. They have 3 days to do so. Ensure your device logs reflect IAP version 3.0.1

 

I am sorry I am not a professional developer, but I manage to have the app running for 3 years without any problem. I don't see any answer in the above, or what to do exactly. I havent implemented Deferred purchases or made any changes to the code, as it is made with unitys codeless iap and the subscription manager, I merely updated the IAP version.. I am running Unity v 2018.4.31 and I dont think I can update to IAP version 3.0.1? Will that be available?
When I test out a test purchase on google play the test purchase also gets cancelled after first subscription period and the mail states that I have to make sure that all purchases are confirmed and links to this link https://developer.android.com/google/play/billing/integrate#process
Do you have a sample code available that works with the new system like you did with the IAP Demo earlier?

 

If you are using IAP 2.2.7, then you are using the Google Billing Library v3. This introduces a new purchase method as described. This is why you've started to see this. I would suggest that you test with the Sample IAP Project. How do you know the subscription is cancelled? You might be seeing something else. But you should implement the deferred listener regardless if you haven't done so already to accommodate this new purchase method. https://forum.unity.com/threads/sample-iap-project.529555/

Add the following to OnInitialized

m_GoogleExtensions?.SetDeferredPurchaseListener(OnPurchaseDeferred);

then add

Code (CSharp):

1. public void OnPurchaseDeferred(Product product)
2.     {
3.  
4.         MyDebug("Deferred product " + product.definition.id.ToString());
5.     }

Can you provide your current device logs? It almost sounds like you are not running IAP 2.2.7 https://forum.unity.com/threads/how-to-capturing-device-logs-on-android.528680/

 

I am running 2.2.7 yes. I double checked, and also in the logs. I think I have fixed the issue now. It seemed I just had to check the "consume" checkbox on the iap listener to make it register that the app had been opened after the subscription purchase. I have never had the consume checked before in earlier versions, so hopefully this is enough to avoid the trial periods to be cancelled and refunded.