[Interest] Checking for refunds - QtPurchasing

[René Hansen]

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> 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>
> 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> *On Behalf Of *René
>> Hansen
>> *Sent:* Wednesday, July 24, 2019 2:04 PM
>> *To:* interest <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/20190724/753cb6c7/attachment.html>