#bugkiller-subscription-cancellation
1 messages · Page 1 of 1 (latest)
Recommend setting cancellation_details on explicit cancel by user so you can tell easily: https://stripe.com/docs/api/subscriptions/object#subscription_object-cancellation_details
Or even just set a field in your database when a user explicitly cancels in your app
There's not a field on the subscription that indicates this right now
Oh actually I might be wrong
Yep we set cancellation_details.reason to payment_failed if due to a cancellation failure, so you can get all the info you need from that field
Can you tell me more details
What do you mean
Just look at cancellation_details.reason on the subscription object
cancellation_details.reason is 'payment_failed'
then we can know this means subscription cancelled due to payment failure not by user's action?
yep
so if subscription was cancelled by user
- by stripe api call to cancel subscriptIon
- by cancel it via stripe dashboard
in above 2 cases, cancellation_details.reason will not be 'payment_failed' ?
Am I correct?
Yes but recommend you just test this out yourself in test mode
That way you can see behavior exactly
just get subscription and then read 'cancellation_details.reaso' ?
yes
Wait why are you retrieving subscription
You get it in subscription_from_event
You just need latest invoice expanded?
But yeah you can check cancellation_details on either subscription_from_event or subscription in your above code
subscription_from_event is just subscription object itself? it has all fields?
Yeah that's how webhooks work
You get the entire object in the payload
Is the above your code?
yes, it's my code
You won't get latest invoice in the payload though since that's not expanded by default
Recommend reading https://stripe.com/docs/webhooks
makes sense
Important to understand how they work
So yeah you do need the retrieve call if you need access to latest_invoice since it's not expanded by default in the payload. But, in general, you don't need to retrieve the object. Most fields will be available in the payload
yeah, if I dont' need to expand the latest_invoice , then getting subscription by calling api again is like waste
exactly
I want to ask one more.
you have subscription , but you want to change the card
what should we do?
Do you already have new card on file?
user will add new card via our website
we will do this mode as 'setup' to make user add card
Ok then just call update subscription to change the default_payment_method: https://stripe.com/docs/api/subscriptions/update#update_subscription-default_payment_method
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
in the success_url end point, we're making it as default payment method
is it good enough or not?
I still need to update subscription's default_payment_method or not?
If you do the above that's fine
thanks
The default payment method on the subscription object always takes precedent though
So if default payment method is set on the subscription level, and you update it on the customer's invoice settings, then the one on the subscription will still be used.
Please just read the link I sent you
It explains all of this
yeah, we're not adding subscription's default_payment_method
so maybe if I update deafult payment method for stripe customer, as I guess it's enough
so asking you double chekc
bugkiller-subscription-cancellation
Yeah but recommend examining some of your subscription objects to make sure it's not set at the subscription level
If you use checkout in subscription mode, it's automatically set
ok, first now testing for the subscription cancellation stuff I asked at first. (to decide if subscription is cancelled by user or cancelled by payment failure)