isn’t there a way to receive billing subs cancellation updates exactly when cancellation happens i.e. when billing period ends? for non-prorated subs cancellations? Also, after prorate:false cancellation the subs disappears from the activeSubscription gql query
Hey again @Jaspreet_Singh - great questions here as always!
For getting notified about subscription status changes, you can subscribe to the APP_SUBSCRIPTIONS_UPDATE webhook topic, which fires when a subscription status changes. The docs on that are here: Combine time and usage-based subscriptions
The challenge though with non-prorated cancellations (prorate: false) is that the subscription status moves to CANCELLED immediately when the cancellation happens, not at the end of the billing period. So the webhook fires right away at cancellation time rather than when the paid period actually ends.
On the activeSubscriptions behaviour you’re seeing, that’s expected but I definitely get that it’s not ideal. Once the status flips to CANCELLED, it drops out of activeSubscriptions. One thing worth knowing is that you can use allSubscriptions on currentAppInstallation instead, which will still return cancelled subscriptions:
currentPeriodEnd returns null for non-active subscriptions, so if you need to know when the billing period actually ends after a non-prorated cancellation, you’d need to be caching that value beforehand. More on the AppSubscription object and its fields here: AppSubscription - GraphQL Admin
Just to better understand your use case, could you share a bit more about what you’re trying to do? Specifically:
- Are you trying to continue providing access to app features until the billing period ends and need a way to know when to cut off access?
- Is this something you’re triggering via
appSubscriptionCancelyourself, or is this happening when merchants uninstall?
That would help me understand if there’s a better pattern for what you’re trying to accomplish, or if this is something I should log as a feature request. Hope to hear from you soon!
Thank you, @Alan_G .
- Yes
- This happens when we cancel via billing.cancel()
Hey hey again @Jaspreet_Singh - thanks for confirming, super helpful.
Totally get the use case here. In the meantime, the pattern I’d suggest is grabbing currentPeriodEnd from the active subscription before calling billing.cancel() and caching it on your end, then gating feature access against that cached timestamp until it passes.
That said, I can definitely see how a dedicated webhook or event that fires at the actual end of the paid period for non-prorated cancellations would make this a lot smoother. Happy to log this as a feature request on our end, can’t guarantee anything but I’ll get it logged!
Let me know if I can clarify anything further.
Thank you, @Alan_G
We have been using the same solution. It seems like the best option for now.
While we are at it, can you please also log feature request for subs reactivation. And I have observed that currently we are able to cancel a subs with prorate: false and immediately get a new subs while the other one is still technically active.
Hey @Jaspreet_Singh, happy to get a reactivation feature request logged for you as well.
On the simultaneous subscriptions issue you mentioned, that’s actually expected behaviour rather than a bug. When you cancel with prorate: false, the status flips to CANCELLED immediately so the merchant keeps access through the end of the paid period, but because the status is already CANCELLED, nothing blocks appSubscriptionCreate from creating a new one alongside it though. So you’ll see one cancelled sub still serving out its paid period and the new active sub running in parallel.
That said, this is basically reactivation via workaround, which is exactly why a a reactivation path would clean this up. I’ll get that logged on our end here.
Let me know if I can help out further 