Fix/avoid blindly consuming success purchases

[AmauryLiet]

The issue

I noticed that using consumeAllItemsAndroid is pretty dangerous in non-dev environnement:
If a purchase becomes successful while the app is offline or killed, then calling consumeAllItemsAndroid will consume the successful purchase without ever notifying the host app, preventing the purchased product from being delivered (although it is billed)

However consumeAllItemsAndroid still appears to be pretty useful in some prod cases:
When a pending payment fails:

• the app is never notified of the fail (Purchase with "Slow card, always denied" is never set as canceled and always fire purchaseUpdatedListener #1012)
• the purchase remains pending due to Play Store cache (related Android issues: How can I handle the case of "Slow test card, declines after a few minutes" android/play-billing-samples#272, https://issuetracker.google.com/issues/73982566 & https://issuetracker.google.com/issues/149668311)

The only way (that I am aware of) to force the cache refresh is to try to consume the pending purchase. You would then get a BillingResponseCode.ITEM_NOT_OWNED error, and the item is available for purchase again. (credit to this post)
This fix was already suggested in some issues: #126 (comment)

The solution suggested in this PR

We should expose a method to flush all failed purchases that are still - wrongly - marked as pending.

It would simply fetch all pending purchases, and try to consume then individually:

• if they are indeed pending, we would get BillingResponseCode.DEVELOPER_ERROR
• if they were actually already failed, we would get BillingResponseCode.ITEM_NOT_OWNED

---

Happy to get your feedback on the implementation/naming/...

I am not a big fan of the "callback hell" of the readme. I guess migrating the example/doc to hooks would help but that a subject for another PR

Worthy discussion:

• should that be the behaviour by default (done by default in initConnection)?

[AmauryLiet]

TODO: update README

[AmauryLiet]

@iaphub @hyochan do you have any feedback on the PR?
is the issue clear to you?

[hyochan]

This is so great to see! Let's see how it goes.
Sorry for the delayed review 🙏

[hyochan]

The issue

I noticed that using consumeAllItemsAndroid is pretty dangerous in non-dev environnement:
If a purchase becomes successful while the app is offline or killed, then calling consumeAllItemsAndroid will consume the successful purchase without ever notifying the host app, preventing the purchased product from being delivered (although it is billed)

However consumeAllItemsAndroid still appears to be pretty useful in some prod cases:
When a pending payment fails:

• the app is never notified of the fail (Purchase with "Slow card, always denied" is never set as canceled and always fire purchaseUpdatedListener #1012)
• the purchase remains pending due to Play Store cache (related Android issues: android/play-billing-samples#272, https://issuetracker.google.com/issues/73982566 & https://issuetracker.google.com/issues/149668311)

The only way (that I am aware of) to force the cache refresh is to try to consume the pending purchase. You would then get a BillingResponseCode.ITEM_NOT_OWNED error, and the item is available for purchase again. (credit to this post)
This fix was already suggested in some issues: #126 (comment)

The solution suggested in this PR

We should expose a method to flush all failed purchases that are still - wrongly - marked as pending.

It would simply fetch all pending purchases, and try to consume then individually:

• if they are indeed pending, we would get BillingResponseCode.DEVELOPER_ERROR
• if they were actually already failed, we would get BillingResponseCode.ITEM_NOT_OWNED

Happy to get your feedback on the implementation/naming/...

I am not a big fan of the "callback hell" of the readme. I guess migrating the example/doc to hooks would help but that a subject for another PR

Worthy discussion:

• should that be the behaviour by default (done by default in initConnection)?

Migrating to react-hook is really a great idea. I am not quite sure what you mentioned on the default behavior on initConnection tough 🤔.