#Jacob Wright
lament knoll
ancient plover
I believe cancellation reason is new as of roughly March 2nd. Let me dig in a bit to see if I can find more info. Do you have a link to the docs you followed to enable this?
ancient plover
I think you might need to look at cancellation_reason on the underlying Payment Intent: https://stripe.com/docs/api/payment_intents/object#payment_intent_object-cancellation_reason
Does that get you oriented in the right direction?
rapid rivet
Unfortunately, that's not the same. We get requested_by_customer for every one.
We see the data in the developer logs for POST /v1/billing_portal/sessions/...
Request POST body
"cancellation_reason_text": "This is feedback",
"cancellation_reason": "unused"
}```But that isn't easily surfaced for individual subscriptions or for aggregate counts.
Since this feature is so new, I am guessing this is the MVP of it and they haven't gotten to exposing this data yet. We will hope Stripe adds it in the future.
This one feature is actually the one that made us decide to move to Stripe's portal rather than staying with our own. Fingers crossed we get this. 😄
ancient plover
Wait, do you have a Request ID for the POST request you're referring to here?
POST /v1/billing_portal/sessions/...
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
rapid rivet
We do, but I didn't want to post it into the public discord
ancient plover
It's totally harmless to post request IDs. No one can do anything with them unless they have your secret API key or Stripe login credentials
rapid rivet
cool
We just need to be able to get that data out of Stripe monthly or weekly to track cancellation reasons over time.
If we can get it in a webhook, that would be great. Or get a chart in Stripe Dashboard, even better
I know this isn't a feature request chat though. So thank you for your help!
ancient plover
Happy to put in the feature request, but I wanted to make sure that we knew with certainty that the data was surfaced on any of the objects. You mentioned you were able to get the cancellation_reason in a POST request:
POST /v1/billing_portal/sessions/...
But as far as I can tell, we only return a Subscription ID in the response for the above request (https://dashboard.stripe.com/logs/req_0FB12eE2xg4a3C). Are you seeing it somewhere else?
rapid rivet
The portal POST includes cancellation_reason_text and cancellation_reason from the customer portal, but it is only returning the id because the query parameter "include_only": ["id"]
In the webhook associated with this cancellation, we get these details
Or rather, in the event https://dashboard.stripe.com/events/evt_1MlG3AGlCGS85NRPatt21txa
rapid rivet
Happy to put in the feature request, but I wanted to make sure that we knew with...
Just to be clear, the POST we found in logs is being created from Stripe's customer portal. We are only finding it in the developer logs. The POST is sending the customer's cancellation_reason of unused and cancellation_reason_text of This is feedback which we entered when testing.
ancient plover
Got it okay, yeah I think that is the default behavior at this point, but I can see why that would be really unhelpful for people that rely on webhooks for this type of thing. Happy to surface the feedback to the product team for you as I can see the need for it
rapid rivet
So I assume Stripe is storing it somewhere, otherwise they won't be posting that from the portal. Just not sure if we can access the data yet.
ancient plover
I'd be surprised if this isn't already in their roadmap, since it's new functionality
rapid rivet
Yeah, I would be too. 😄 Thank you for your help today!