#jonah-subscription-cancel

1 messages ยท Page 1 of 1 (latest)

lofty flameBOT
pastel copper
#

jonah-subscription-cancel

#

For #1, if you cancel, the Subscription is done/canceled and it's a terminal state. If they want to resume their Subscription in a few months you would create a brand new Subscription

true pecan
#

For number 1, would it then be recommended to pause forever until they resume again?

pastel copper
#

that's really up to you really, depends what you want out of this

true pecan
#

Users have a 30-day cycle. They can choose to "pause/cancel" and then just "resume" it again at a later date.

#

Most convenient for them would likely be to just pause. I'm missing the upside to cancelling beyond docs jargon.

pastel copper
#

We don't really have a "pause" logic in our API. So you either cancel, or switch them to a free Price maybe in the meantime. It's really up to you as a business to decide what fits best for you

true pecan
#

Ah

#

So "pause payment collection" could effectively be the pause

#

And it's my choice what to do on the front-end when the "payment collection" is paused.

pastel copper
#

no I would recommend never use "pause payment collection" at all for your use-case.

#

It was built for something drastically different like during COVID when most businesses wanted to stop charging their customers entirely while they figured things out

true pecan
#

Gotcha.

So cancel, but just keep then keep payment info so we can just create a new subscription whenever the user wants to resume

pastel copper
#

yeah that's what I'd do

true pecan
#

Okay, only caveat here:
if they cancel before the end of their cycle, then create a new one.... is there a simple way to not charge them for the new one until the end of the current cycle?

pastel copper
#

that marks the Subscription to cancel at the end of the current period. And you can undo it (set it to false) if they change their mind

true pecan
#

Would the cancel_at_period_end be called in subscription.update?

You sent the create_subscription url

#

And I see there's params for that at both.

#

So if cancel_at_period_end is passed in on creation, I'd assume this would only matter if I then call subscription.cancel.

And then would have to subscription.update if I want to cancel.

Or maybe I can do it both ways?

pastel copper
#

yeah both ways work, it exists on create and update

true pecan
#

Do you recommend having it just use the previous payment information in the new checkout links?

pastel copper
#

I don't really understand what that could mean

#

what's a "new checkout link" exactly?

true pecan
#

e.g, if they renew a cancelled subscription

pastel copper
#

Are you talking about Checkout, our product? Or something unrelated?

true pecan
#

checkout ya

pastel copper
#

Checkout?

true pecan
#

Yea

pastel copper
#

sorry, I'm nitpicky, but every developer says "checkout" for their own payment form ๐Ÿ˜…

true pecan
#

Oh ahahah

#

Like a checkout link

pastel copper
#

lol you say Checkout again with no capital C :p

true pecan
#

Oh

#

LOl

#

Checkout

pastel copper
#

Then you don't really control any of this yourself really. But yes, you send them to a new Checkout Session's URL and it would have the existing Customer id cus_123 associated with that Session. In that case we (Stripe) will show their previously saved card if any yes

true pecan
#

Awesome

#

And one more q

#

If payment fails

#

Suppose it takes them 2 weeks to resume

pastel copper
#

A Checkout Session expires after 24 hours though so that won't really work

true pecan
#

will that subscription wait to set a new expiry date until the payment is filled?

#

No I mean for automatic renewal. Sorry

pastel copper
#

I'm so sorry, I have no idea what any of this could mean. You seem to be using the Stripe vocabulary a bit differently so I'm totally lost ๐Ÿ˜…

#

Can you maybe give concrete examples with example dates of what you mean?

true pecan
#

Okay, so my subscription has 30-day renewal cycles.

After 30-days, it will bill again. But on the second time, the payment fails.

I want the 30-days to start from when the payment succeeds again, i.e, the user changes their payment info.

#

What's the best way to call the APIs so that works out?

pastel copper
#

ah yeah that is completely impossible really

#

so I would strongly encourage you to change your business model to never work this way