-
I'm trying to decide whether I also need to use https://github.com/jinseokoh/purchase-webhooks or not to handle this particular use-case? Am I understanding correctly that the SubscriptionCanceled from this package, or any event really, would not be triggered in the case that a user cancels/refunds their subscription, or any other IAP, by going through a process external to the client app? In this case, then a user could continue to use a subscription/item and it wouldn't be known to us unless we paid close attention, but denial of the use of the IAP or subscription wouldn't be automated? Is that the case? Or does this package also address this now? On a side note, I'm also try to decide if this package is a complete replacement/alternative to the older https://github.com/aporat/store-receipt-validator? Or if there are other considerations I should be looking at in choosing one or the other. Generally I would tend to side with this one here since it's made for Laravel and seems to be more actively developed Many thanks for making this and for your time reading this issue! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Thank you for starting this discussion @vesper8!
If you enabled the server notifications you will receive a notification after any particular event happens. And yes the SubscriptionCanceled event will be triggered if the user used any external process to the client app.
This package is made directly for Laravel to handle receipt validations and server notifications for both providers Google Play and App Store in a unified way. |
Beta Was this translation helpful? Give feedback.
Thank you for starting this discussion @vesper8!
If you enabled the server notifications you will receive a notification after any particular event happens. And yes the SubscriptionCanceled event will be triggered if the user used any external process to the client app.