NEW WARNING: Google Play Billing

@famousdoggstudios check out: Google Play's IAP Auto-Refunds Big Problem - #6 by troylyndon

I had this same problem months ago, until I realized the problem was not including a delay between finish and consume - check out the last entry in this topic post for precise details on how I fixed this. Now, we rarely see refunds.

Coincidentally, I too have a delay in my code before i consume a purchase— i had written my IAP script some years back and never added a comment as to why the delay was added so this might have been the reason

However, i think this pertains to automatic refunds from google and not the scenario where users successfully request a refund to exploit the system. They usually claim refund under “accidental purchase” and get their money back as well as the in-game product/entitlement

Does the new IAP plugin also support Google Play’s new subscription features that were rolled out in May 2022?

https://www.androidpolice.com/google-i-o-2022-brought-the-biggest-changes-ever-to-google-play/

Basically the ability to handle different plans and offers?

Thanks!
Andrew

@Scott_Harrison We have a truly weird issue. We’ve made the required updates to the build.setting. My colleague, a remote developer, was able to create builds that work. However, it doesn’t seem to work for me. When I create the build and test on the test device, I see that the app receives the “initialized” event, but no other events. Also, the actual native purchase menu doesn’t show up either.

He and I have both downloaded the same code base, same Corona version (2022.3677 (2022.8.2)), we even compared the Cached plugin data.tgz that’s downloaded into Solar2DPlugins/Coches/ to be the same. We also tested the same device but with builds from his machine vs mine, and his works, but mine doesn’t.

Is there anything else that we need to make sure this plugin works? eg. SDK version, deleting old plugin from a hidden cache, etc? We are pretty much at a dead end…

Are you both running the same OS? (Windows or Mac)

Hi all,
I believe there is a bug in V2 plugin, regarding acknowledging subscriptions.
After calling finishTransaction on subscription, subscription is not acknowledged and is refunded to user.

I believe problem is in:
private int finishTransaction(LuaState L) {

getPurchasesFromTransaction(L, true, processPurchases); // this is called in IAPsOnly mode (2nd param)

}

Would be great to fix that :slightly_smiling_face:

Tom

@tommy_42 and @akao see NEW WARNING: Google Play Billing - #31 by Scott_Harrison

Edit: @akao to answer your question about multiple plans and offers, that is not currently supported by new IAP plugin

@Scott_Harrison is there any other way (another plugin or something) that could help them? Would going Native help them?

Sorry about that, I opened a new issue
Tom

1 Like

Help them with what?

Support for the new subscription options - Native only?

We finally figured out what the issue is. The issue is that we have a piece of code that gets the product info slightly before initializing the store. Somehow this created a race condition where it seems to trigger an error in the plugin that effectively crashes the plugin. So, we basically needed to make sure we initialize the store first.

@Scott_Harrison Maybe something to consider to make the plugin a bit more robust?

@akao @troylyndon the main issue with supporting more offers and making the plugin more “robust” is that it would not be cross compatible with the store api for other platforms.

1 Like

Solution implemented by Scott and documented here: Solar2D Documentation — Plugins | google-iap-billing-v2

@Scott_Harrison was anything changed recently on this plugin? Initially i migrated to this plugin and was working ok, but in the latest build i created in the past couple of days. Im getting this multiple purchase problems for any app i’m building.
for example.
if the user is buying 1000 coins. my builds from a week ago would give 1000 coins and show an alert that they got the 1000 coins.
Built today, no changes to my code, and when the user buys 1000 coins, 3000 coins are given, and 3 x the same alert shows up from the purchased state. so the only thing i can see is the purchase state is being called multiple times

Is there some sample code how the publisher ID has to be included in the build.settings ?
And maybe a newly configured transactionlistener code sample?

According to the GitHub page, there was an update to version 11 on October 11.

I suggest using the new(ish) “version force” feature to go back to version 10 (from September 12) to see if the problem disappears. If everything works, it was definitely a change from version 10 to 11 that is causing the problem. (You can also just use the old version if you need to publish right away.)

Your build.settings code would look like this:

["plugin.google.iap.billing.v2"] =
        {
		publisherId = "com.solar2d",
		version = "v10",
        },

In one of my earlier posts on this topic, I had mentioned facing this same problem. Can you confirm that you are facing this in an actual production build and not a live build?

I generally test features through live builds and had this exact same thing happen on my app but when I tested the plugin by generating a proper APK and installing on my devices, I did not face this issue.

Yes this is a production build. I dont use live builds. i only noticed once i went live with the aab file, and noticed the bug while testing…

I tried my other apps and also same issue with multiple calls to transaction.state == “purchased”

What is strange, is sometimes it seems to fire twice, eg, 2000 coins gets set to 4000 coins with 2 alerts. and sometimes its firing 4 or 5 or 6 times with those alerts. and i have no idea why or what is causing it to fire that many times.

for the app i went live with I created a temporary workaround setting a bool to true when a purchase button is pressed and false once the initial purchase state is initiated the first time. so it doesn’t loop through the purchase state… but something is not right that’s for sure. @colinmorgan i’ll give that a try and see if using the version force for the previous version of the plugin fixes this.