Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concern regarding getAvailablePurchases() #970

Closed
nastarfan opened this issue Apr 11, 2020 · 11 comments
Closed

Concern regarding getAvailablePurchases() #970

nastarfan opened this issue Apr 11, 2020 · 11 comments
Labels

Comments

@nastarfan
Copy link

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

@ue
Copy link

ue commented Apr 16, 2020

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.

@creativemind1
Copy link

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.

@darriuk
Copy link

darriuk commented May 7, 2020

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?

@vkachan
Copy link

vkachan commented May 7, 2020

@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.

@darriuk
Copy link

darriuk commented May 8, 2020

@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.

@doteric
Copy link

doteric commented May 12, 2020

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? 🤔

@tomerdev
Copy link

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.

@captaincole
Copy link

@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.

@tomerdev
Copy link

tomerdev commented Jul 4, 2020

@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.

@stale
Copy link

stale bot commented Oct 3, 2020

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.

@stale stale bot added the 🚶🏻 stale Stale label Oct 3, 2020
@stale
Copy link

stale bot commented Nov 5, 2020

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.

@stale stale bot closed this as completed Nov 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants