search

voltrue2 / in-app-purchase

A Node.js module for in-App-Purchase for iOS, Android, Amazon and Windows.
http://iap.gracenode.org
Other
1.05k stars 289 forks source link

google status code 410 should be handled as end-of-subscription, instead of error. #153

Closed jngbng closed 6 years ago

jngbng commented 6 years ago

Please refer to https://stackoverflow.com/questions/45688494/google-android-publisher-api-responds-with-410-purchasetokennolongervalid-erro

voltrue2 commented 6 years ago

Hello

Thank you for reaching out. I will have a look at this!

Cheers

voltrue2 commented 6 years ago

@jngbng After looking into this response with 410. It seems that Google is telling us the subscription is no longer valid. I think it should still be treated as an error. If you think otherwise, would you please provide an example case where you would want this to be treated otherwise?

Cheers!

eranpolo commented 6 years ago

Hi, @voltrue2 - we just stumbled upon this in our production code (got 410 and mishandled it).

If 410 isn't to be treated as "end-of-subscription", perhaps small changes should still be made:

  1. Info added to the iap docs, otherwise developers will miss this subtlety.
  2. The returned error object should contain the HTTP response code in a clean way, and not just as part of an error string. Will be cleaner to parse and respond to this case.
voltrue2 commented 6 years ago

@jngbng @eranpolo My apologies for taking forever to get to this. I just added an error check for this case and now it returns a specific error when the library sees status 410 from Google.

Cheers!

jngbng commented 6 years ago

@voltrue2 In my opinion, 'error' should be for exceptional cases which has nothing to do with business logic, such as network error or authentication errors. In this case, I think the response is not temporally unhandleable error and the subscription would not be logically valid for good. Therefore, we would better treat it as 'end-of-subscription' or another logically valid response (not an error). I wonder why google designed this way, though. :(

anshul-kai commented 6 years ago

I'm just encountering this issue as I've only recently started querying older receipts (expired subscriptions). Do we not receive any data for expired subscriptions from Google? It would be very helpful to query data for older receipts.

Thoughts @voltrue2?

voltrue2 commented 6 years ago

It seems there’s no way to query for expired receipts with Google at the moment. I will go through the documentation again to make sure I haven’t missed anything. In the meantime, do you think it helps to have a way of mass-validating receipts for expired receipts? Something like iap.areExpired(receipts)?

On Aug 15, 2018 at 16:11, <Anshul Koka (mailto:notifications@github.com)> wrote:

I'm just encountering this issue as I've only recently started querying older receipts (expired subscriptions). Do we not receive any data for expired subscriptions from Google? It would be very helpful to query data for older receipts.

Thoughts @voltrue2 (https://github.com/voltrue2) ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (https://github.com/voltrue2/in-app-purchase/issues/153#issuecomment-413113784), or mute the thread (https://github.com/notifications/unsubscribe-auth/ACKY4esN_SDYdnWlteRCREZZhQQ5mgx_ks5uQ8mmgaJpZM4R8B4l).

anshul-kai commented 6 years ago

I verified the docs and you're right @voltrue2. I implemented a very hack way to retrieve expiration dates of old receipts. It's a bummer that Google won't provide us data on old receipts.

Regarding mass validation, my particular use case doesn't quite require it. Does Google expose an API to do this or are you considering a wrapper function? A wrapper function won't bring much value IMO as most developers should be able to accomplish this themselves.