Java – In-App Billing v3 reliability flaw

In-App Billing v3 reliability flaw… here is a solution to the problem.

In-App Billing v3 reliability flaw

First, thanks to Google for the new IAB API, it seems to be easier to use compared to the previous API. The new example is also a huge leap forward compared to the old example, and so far only one crash has occurred in MainActivity.onDestroy() due to the lack of super.onDestroy().

But I don’t quite understand one statement:

You must send a consumption request before provisioning the benefit of
the consumable in-app purchase to the user.

Following this guideline, if the application dies immediately after executing the consumption request, the purchased elements appear to be lost. Previous implementations provide periodic IN_APP_NOTIFY broadcasts until the purchase is confirmed, but the new implementation lacks it. I don’t see how to reliably deliver the project unless you implement your own purchase flow tracking, which will be persisted and definitely complicate the code. So, does the new approach look like a flaw in the implementation or am I missing something?

Also, in my case, the configuration, including validation, is done on the server side. I was wondering if I should ignore the cited guide and consume it before providing it. With this method, I don’t have to worry about items being lost as soon as the purchase is complete. If the app crashes, the project remains “owned” until I do server-side configuration and then consume. Is it okay from a security perspective?

Solution

I agree. I process the transaction on the server (success or verification failure) and mark it as used.

Related Problems and Solutions