React-native-iap: Concern regarding `getAvailablePurchases()`

Created on 11 Apr 2020  ·  11Comments  ·  Source: dooboolab/react-native-iap

Version of react-native-iap

4.4.3

Version of react-native

0.61.6

Platforms you faced the error (IOS or Android or both?)

Android

Expected behavior

First of all, thanks for all the efforts you put to make and maintain this library, really appreciate it.

getAvailablePurchases() should not return subscription that's canceled (not renewed)

Actual behavior

in the test environment (using test account with test card), when i make subscriptions on my app and cancel the subscription before the expiracytime (5 minutes after purchase in the test account), my subscription won't be listed in the result of getAvailablePurchases() when expiracytime is exceeded. Which is a desired behavior.
However, if i let my subscription to renew (by not canceling before renew period), and then cancel it after that, getAvailablePurchases() would still list my subscription, even after expiracytime is exceeded. My question is, why does it still list subscription I no longer subscribed to?

Also, I want to know the details regarding getAvailablePurchases(), does it make a call to google billing to retrieve available purchases? or does it keep the purchase list locally?

test setting: https://developer.android.com/google/play/billing/billing_testing#testing-subscriptions

Tested environment (Emulator? Real Device?)

real device

Steps to reproduce the behavior

subscribe to a subscription, let it get renewed, then cancel. The subscription would still be listed as available purchases

🚶🏻 stale

Most helpful comment

@darriuk I just tested cancelling subscription and confirm that autoRenewingAndroid property is set to false. But! Only if user cancels subscription explicitly. In case of cancelling subscription due to declined payment the subscription stays active forever. This is really big issue with subscriptions and there is no workaround. I had an idea to compare transactionDate and if this date is behind subscription term, then do cancel service on my side. But it seems like transactionDate is always first date of payment for subscription.

All 11 comments

I would like to add couple of question. What if we don't use backend services for validation. how can I understand the subscription done and canceled by the user. how can I handle that?.
Also in my sandbox account has 6 subscription products. All of them are active how it can possible?
FOR IOS.

Apple suggest strongly to use server validation because of risk of being hacked.

I have wrote a backend API which takes the receipt of the user and verify that. If found no latest transaction, it means the user hasn't subscribed so I'm making that user a non-premium (or whatever you wish to do). I call this API at the opening of the App. My App checks daily.

I am also seeing similar behaviour with getAvailablePurchases. The expected behaviour is that after a subscription is cancelled, the getAvailablePurchases method should return the purchase up until it expires. After expiry the purchase should not appear in getAvailablePurchases results (with a grace period of 5 mins added if expiry was caused by failure of repeated subscription payment).

The actual behaviour is after cancelling a subscription thegetAvailablePurchases method returns an array containing the subscription purchase, _even after the sub expires_. The only clue that the sub is cancelled is that within the returned SubscriptionPurchase object the autoRenewingAndroid property is set to false.

I have no clue when the purchase is removed from results returned by getAvailablePurchases. Does anyone know?

@darriuk I just tested cancelling subscription and confirm that autoRenewingAndroid property is set to false. But! Only if user cancels subscription explicitly. In case of cancelling subscription due to declined payment the subscription stays active forever. This is really big issue with subscriptions and there is no workaround. I had an idea to compare transactionDate and if this date is behind subscription term, then do cancel service on my side. But it seems like transactionDate is always first date of payment for subscription.

@vkachan as far as I recall the transactionDate is indeed always for the first subscription payment.

One update from me: I ran getAvailablePurchases again approx 22 hours after cancelling subscription and it is finally returning an empty array. It looks like Google's billing server is just taking ages to update the response.

I'm going to try a declined subscription payment today and see how long it takes to be removed from the getAvailablePurchases response.

UPDATE
I tested declined subscription payment and getAvailablePurchases took approx 32 hours to return an empty array. So the purchase _does_ get removed eventually, it just takes a good while to happen.

Can confirm what @darriuk is saying. I've ran a test subscription it ended and then the subscription was still presented as active from getAvailablePurchases for about 24 hours. Maybe there is some way to force reload by Googles side? 🤔

Had similar issues, handling iap on the client side is a mess, now using react-native-iaphub.
Iaphub takes care of the server receipt validation.

@tomerdev What has your experience been like with iaphub? I was thinking of moving over to using it but wanted to see what another dev thought of the product.

@captaincole No issue using iaphub, implemented the library and made a sandbox purchase pretty fast.
It definitely saved me a lot of time. I would recommend it if you can't spend A LOT of time to take care of IAP, I personally prefer to focus on my app.

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open. Thank you for your contributions.

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.

Was this page helpful?
0 / 5 - 0 ratings