#bugkiller-subscription-cancellation

1 messages · Page 1 of 1 (latest)

hexed flaxBOT
compact mesa
#

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

old drum
#

Can you tell me more details

compact mesa
#

What do you mean

#

Just look at cancellation_details.reason on the subscription object

old drum
#

cancellation_details.reason is 'payment_failed'
then we can know this means subscription cancelled due to payment failure not by user's action?

compact mesa
#

yep

old drum
#

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?

compact mesa
#

Yes but recommend you just test this out yourself in test mode

#

That way you can see behavior exactly

old drum
#

hmm, got it.

#

can I know this information in

#

customer.subscription.deleted webhook?

compact mesa
#

yes

#

Again. Just recommend testing this out in test mode yourself

old drum
#

just get subscription and then read 'cancellation_details.reaso' ?

compact mesa
#

yes

old drum
#

something like this.

compact mesa
#

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

old drum
#

subscription_from_event is just subscription object itself? it has all fields?

compact mesa
#

Yeah that's how webhooks work

#

You get the entire object in the payload

#

Is the above your code?

old drum
#

yes, it's my code

compact mesa
#

You won't get latest invoice in the payload though since that's not expanded by default

old drum
#

makes sense

compact mesa
#

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

old drum
#

yeah, if I dont' need to expand the latest_invoice , then getting subscription by calling api again is like waste

compact mesa
#

exactly

old drum
#

I want to ask one more.

#

you have subscription , but you want to change the card

#

what should we do?

compact mesa
#

Do you already have new card on file?

old drum
#

user will add new card via our website

#

we will do this mode as 'setup' to make user add card

compact mesa
old drum
#

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?

compact mesa
#

If you do the above that's fine

old drum
#

thanks

compact mesa
#

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

hexed flaxBOT
old drum
#

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

indigo dagger
#

bugkiller-subscription-cancellation

compact mesa
#

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

old drum
#

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)