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 <ren...@gmail.com>
Sent: Wednesday, July 24, 2019 4:49 PM
To: Maurice Kalinowski <maurice.kalinow...@qt.io>
Cc: interest <interest@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
<ren...@gmail.com<mailto:ren...@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.kalinow...@qt.io<mailto:maurice.kalinow...@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-boun...@qt-project.org<mailto:interest-boun...@qt-project.org>> On
Behalf Of René Hansen
Sent: Wednesday, July 24, 2019 2:04 PM
To: interest <interest@qt-project.org<mailto:interest@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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
