#raz4395
crude ploverBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- raz4395, 4 hours ago, 14 messages
still belfry
Hi there 👋 no, I would not expect that, as the Customer Portal currently cannot be used to make adjustments to Subscriptions that are being controlled by a Subscription Schedule
https://stripe.com/docs/customer-management#customer-portal-limitations
It sounds like instead your flow is allowing your Customer to update or cancel their Subscriptoin. So I think you'd want to look for customer.subscription.updated or customer.subscription.deleted (depending on your settings).
ruby moat
hi, so after the previous discussion I went ahead and implemented that flow but I do not get this event sent to my webhook when I tried to cancel the subscription
ah, I see, I was looking at customer.subscription.updated
but the only parameter from that event's object that could help me identify that specific cancel action would be
"cancel_at_period_end": true,
and this would overlap with other subscription update events that are made to already cancelled subscriptions
so not sure how to differentiate between a first time cancelation subscription update and other updates
still belfry
Do you have more specifics about what you're trying to differentiate between?
ruby moat
so if a user goes to the billing portal and cancels their sub is one event I want to keep track of
but only that specific cancellation
the second event is resuming their subscription, when a user goes to the portal and resumes, I want this to be my 2nd tracked event
so those 2 subscription_update events I want to differentiate
still belfry
Okay, and what trouble are you running into differentiating those in your testing?
ruby moat
I tried checking if this object exists in the event object:
"cancellation_details": {
"comment": null,
"feedback": null,
"reason": null
},
but it seems to exist in both cases
I should probably go for
"cancel_at_period_end": false,
is that plausible?
still belfry
Hm, not sure I'm grasping what you're saying. Are you looking at data.previous_ajttributes to see exactly which fields changed that triggered the Event to be sent, and then comparing those to the values set in data.object?
https://stripe.com/docs/api/events/object#event_object-data-previous_attributes
That'll let you figure out exactly what changed, so you can look for the changes you care about.