In-App Billing v3 reliability flaw

Question

First, thanks Google for new IAB API which seems to be much easier in use comparison to previous one. Also new example is a great leap forward comparison to old one, so far only one crash at MainActivity.onDestroy() due to missing super.onDestroy() .

However I don't quite get one statement:

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

Following this guideline, seems that purchased item will be lost if app dies right after execution of consumtion request. Previous implementation provided periodical IN_APP_NOTIFY broadcast until purchase is confirmed, but new implementation lacks it. I see no way how I could reliably provision item except implement own tracking of purchase flow which will be persistently stored and definitely complicate the code. So, does new approach look like flaw in implementation or am I missing something?

Also, in my case provisioning (including verification) is done on a server side. I am thinking shall I ignore that quoted guideline and do consumption before provisioing. With this approach I don't have to worry that item will be lost right after purchase is done. if app will crash, item will be kept as "owned" until I'll do server side provisioning and then consumtion. Would it be fine from security perspective?

Answer 1

I agree. I'd process the transaction on the server (either successfully or if it fails validation unsuccessfully), then I'd mark it as consumed.