[Interest] Checking for refunds - QtPurchasing

[Maurice Kalinowski]

Hi,

I would recommend to open a ticket at https://bugreports.qt.io/secure/Dashboard.jspa That way the developer taking care of this module will be able to track and comment in the right place.

BR,
Maurice


From: René Hansen <renehh at gmail.com>
Sent: Wednesday, July 24, 2019 4:49 PM
To: Maurice Kalinowski <Maurice.Kalinowski at qt.io>
Cc: interest <interest at qt-project.org>
Subject: Re: [Interest] Checking for refunds - QtPurchasing

A bit of further testing on this has offered a few more conclusions.

I was wrong in assuming network connectivity was needed. Turning on Flight Mode and calling restorePurchases() still yields a callback of onPurchaseRestored(), so the billing api must cache this information locally on the phone somewhere.

One caveat though. The callback to onPurchaseRestored() only triggers once per Store {} element during the lifetime of the application. I guess that means, if you'd like to have a check on startup, invalidating a purchase in the case where onPurchaseRestored() is not called, as well as having a restore button somewhere on a buy page, that triggers the same, you'd need two different instances of Store {}, with the same product, in order to accomplish that.

I know refund abuse is commonplace, so would have hoped for a better solution. It seems backwards and very brittle this way.


/René



On Wed, 24 Jul 2019 at 15:18, René Hansen <renehh at gmail.com<mailto:renehh at gmail.com>> wrote:
Ok, so I'm supposed to call restorePurchases() and then check whether "onPurchaseRestored" was *not* called for a specific Product? And in that case assume it was not purchased and/or refunded?

That's going to be very error prone I think, because then I guess I'll have to do all the usual timeout checking, network connectivity assertion etc. etc.

If only Store had something like:

https://developers.google.com/android-publisher/api-ref/purchases/voidedpurchases/list


/René

On Wed, 24 Jul 2019 at 14:12, Maurice Kalinowski <Maurice.Kalinowski at qt.io<mailto:Maurice.Kalinowski at qt.io>> wrote:
Hi,

It’s been a while I had a look at Qt Purchasing, but generally https://doc.qt.io/qt-5/qinappstore.html#restorePurchases was talking to the store (at least Microsoft Store) to re-verify active purchases.
If something has been refunded and/or revoked, then those should not be listed anymore. But generally, restorePurchases does not only check locally, but refers to what the store currently states.

BR,
Maurice


From: Interest <interest-bounces at qt-project.org<mailto:interest-bounces at qt-project.org>> On Behalf Of René Hansen
Sent: Wednesday, July 24, 2019 2:04 PM
To: interest <interest at qt-project.org<mailto:interest at qt-project.org>>
Subject: [Interest] Checking for refunds - QtPurchasing

Hi all,


I'm not sure this is solvable via QtPurchasing currently, but if anyone has solved it, I'd love to hear about your approach.

Normally a purchase flow goes something like this:

1. Purchase happens.
2. Transaction information is returned.
3. If transaction was approved, some value is stored locally in the settings or otherwise persistent storage, indicating this item was bought.
4. Subsequent launches checks for the above set value, in order to determine if user previously bought said item.

Here's what I haven't figured out how to solve. What if this additional step occurs:

5. User is issued a refund.

Is there any way using QtPurchasing to "re-check" the status of a transaction, in order to deactivate any features or similar, which was unlocked by a purchase?


/René


--
Never fear, Linux is here.


--
Never fear, Linux is here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190725/cc43c78e/attachment.html>