How can I use "refunded" state with new Google In App v3?

[JonPM]

Again, if I were you I would completely ignore the “refunded” state, it’s useless.  As the developer, all you really care about is is this item purchased?  If purchased, app is unlocked, if not app remains locked. There is no concern to the user flow because as I stated earlier a user cannot get a refund for an IAP from within your app nor the Play Store. 

The only way I can see a refund being potentially useful is if you issue the user a refund on a consumable item (let’s say they bought 100 coins).  In that case you can test for the refund state and subtract 100 coins from their in-app balance.  

[csavalas]

@JonPM

Again, if I were you I would completely ignore the “refunded” state, it’s useless.  As the developer, all you really care about is is this item purchased?  If purchased, app is unlocked, if not app remains locked. There is no concern to the user flow because as I stated earlier a user cannot get a refund for an IAP from within your app nor the Play Store. 

The only way I can see a refund being potentially useful is if you issue the user a refund on a consumable item (let’s say they bought 100 coins).  In that case you can test for the refund state and subtract 100 coins from their in-app balance.  

I was asking Rob about the “refunded” thing because I was debating doing a hybrid of your method and the “refunded” method. From what I understand of your method, if the user never actually turns their phone off or never kills the app manually, it will never lock itself back up since you’re allowing the unlocked state to persist through suspend/resume. I’m considering having the default state of the app be locked at startup before init() and restore() are called. And then in the case that the users gets refunded, but never turns their phone off/kills the app, I’d still like to catch refunded() at some point, hence my question to Rob about how “refunded” comes in. (Or to you if you know the answer lol).

I am reasonably comfortable about setting the default state to locked at every startup, but not really comfortable with locking and unlocking it at every “applicationSuspend”/“applicationResume”, for a variety of reasons. So if “refunded” indeed comes in only when restore() is called, then I’ll simply call restore() every “applicationResume” to try to catch it. I only want to call restore() if necessary though.

[JonPM]

The app will eventually be killed by the OS (to free up memory).  It will not remain in suspended state indefinitely.  

I personally would not advise locking/unlocking at every suspend/resume state.  

[csavalas]

[quote name=“JonPM” post=“314776” timestamp=“1450747167”]The app will eventually be killed by the OS (to free up memory).  It will not remain in suspended state indefinitely.     I personally would not advise locking/unlocking at every suspend/resume state. [/quote] Interesting, I knew apps COULD be killed by the OS, but not that they definitely WOULD be at some point. So looks like I’ll take the plunge with your idea. Were you ever able to figure a workaround for your select users. I already have a saved local variable for the paid state, but I can’t see that helping if I’m locking it at startup anyway. You’ve been a lot of help, I’d like to download one of your apps, I promise I won’t ask for a refund ; )

[JonPM]

I’ve made some medical apps and one word game called Word Crumbs.  I suffer from having too many project ideas and almost zero time

I will send you PM regarding your question.

[csavalas]

Rob, I know the thread has gotten fragmented, but I still would love to know if it is necessary to call restore to get “refunded”, or if it comes in at any given time after an init() call. Thanks

[rob]

You can ignore refunded() and let the user get free stuff. Therefore it’s totally up to you.

JonPM’s system works, do the restore() process every start up and unlock what gets purchased. Then process what events you get. If you get a purchased event that unlocks something unlock it. If you get a refunded event, lock it back. This is a reasonably fail-safe system. The drawback is that if the device doesn’t have a network connection (i.e. Airplane mode), you won’t get any purchased/restored events so you won’t ever unlock things.

The other way to think about is do you want to respect their purchases while they are off line, then you have to leave things that you believe are unlocked and then if they delete the app and reinstall it, give them a restore button (this is the Apple way) to get their purchases back.

Its all a level of trust. Jon’s method is simple and will work as long as you know that they will be locked out while offline.

Rob

Rob

[csavalas]

@rob

You can ignore refunded() and let the user get free stuff. Therefore it’s totally up to you.

JonPM’s system works, do the restore() process every start up and unlock what gets purchased. Then process what events you get. If you get a purchased event that unlocks something unlock it. If you get a refunded event, lock it back. This is a reasonably fail-safe system. The drawback is that if the device doesn’t have a network connection (i.e. Airplane mode), you won’t get any purchased/restored events so you won’t ever unlock things.

The other way to think about is do you want to respect their purchases while they are off line, then you have to leave things that you believe are unlocked and then if they delete the app and reinstall it, give them a restore button (this is the Apple way) to get their purchases back.

Its all a level of trust. Jon’s method is simple and will work as long as you know that they will be locked out while offline.

Rob

Rob

Thanks Rob, that’s not what I was referring to, but I’ve taken enough of your time on this topic already, so no worries!

[JonPM]

I think to answer your question, yes you need to call restore() to get the refunded state (to communicate with server and get updated states).  There is no Runtime event listener that is constantly checking for changes.