#whimsy_subscription-event

1 messages · Page 1 of 1 (latest)

teal forgeBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1304208301419921438

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

patent marsh
#

Hello! What specific data do you want?

glacial oak
#

hm i'd mostly be interested in like if downgrade or upgrade happened

patent marsh
glacial oak
#

ah yeah maybe, what would be best way to check when subscription was canceled by a user and when it is actually stopped (when what they paid for is over)

#

how i did it before is i'd check if cancel_at_period_end was set in customer.subscription.updated and wasnt in previous_attributes

patent marsh
#

It would depend on how your integration works. It sounds like that might be appropriate, but you said you did that before? Before what? Does it not work anymore? If so, why not? What changed?

glacial oak
#

no i mean it does, but im basically abstracting my system into mini package for my own use, im wondering if that's actually the right way to check when normal subscription ends and when its canceled or is that just luck that i found that way which might possibly break

patent marsh
#

If that works for your integration and the way you're using Subcriptions then yes, that's fine.

glacial oak
#

hm

patent marsh
#

There are many different ways to handle/implement Subscription cancelations, so your solution might work well for your integration but might not work well for a different integration. There's no single universal way to do what you're talking about because Stripe Subscriptions are complex and can be used in many different ways.

glacial oak
#

i mean yeah, the way i do it is what i just read in the docs, i create checkout session with subscription data and then if user wants to cancel it, i send them to customer portal

patent marsh
#

Right, that's just one way to do this though. Some people don't use the Customer Portal at all. Some people don't use cancel_at_period_end at all.

#

That's why this might work well for your specific integration, or it might not. It depends on how your integration works and what you've built.

#

You know more about your integration than I do, so you're better positioned to determine if this is the correct approach or not.

glacial oak
#

what are other ways to do that, you could fetch their subscriptions and then show them in their own ui and use cancel via api? but wouldnt that also change cancel_at_period_end

#

i mean yeah, some dont use webhooks at all, but just do it directly if they cancel it via api

patent marsh
#

Some people use Subscription Schedules to cancel an upcoming cancelation. Others schedule a job on their end to call the cancel API at the appropriate time, in which case nothing on Stripe's end would be aware of the upcoming cancelation. There are a myriad of other ways to do this as well.

glacial oak
#

ah yeah that sounds already complex

patent marsh
#

Neither of those examples would touch cancel_at_period_end, which is why I chose them.

#

That's my point: Subscriptions are very powerful because they have a lot of functionality and different ways to do things. This allows them to accommodate many different use cases, but it also make it impossible for there to be a single correct way to do certain things.

glacial oak
#

true, thanks ill test out

patent marsh
#

Happy to help!

glacial oak
# patent marsh Happy to help!

i kinda also just realized that instead of using cancel_at_period_end i could've checked if subscription.data.status is canceled and event.data.previous_attributes.status isnt

patent marsh
#

Yep, that's useful to see when a Subscription actually transitions to canceled.

glacial oak
#

i found broken link in nodejs client

patent marsh
#

Where?

glacial oak
patent marsh
#

Wait, where are those links? What's shown on your video?

glacial oak
#

oh oops

patent marsh
#

You can fix those by adding docs. in front of stripe.com in those URLs, but I want to find and fix those on our end.

#

Oh, it's in the Node SDK comments, I see. Thanks!

glacial oak
#

yeah

#

small last question do you by chance know any scenario when subscription could go from canceled to active status, and how

patent marsh
#

No, once a Subscription is canceled that's it, it's done.

glacial oak
#

its not .crop but yes

patent marsh
#

Oh, my bad, sorry!

#

Fixed.

#

Side effect of me reporting that issue with the links in the Node SDK. 😅

glacial oak
#

ah haha, is there a way to add/modify items/products to existing subscriptions? if so, how would user be notified about that? like if i they buy some subscription and they want to purchase "an addon" which is basically just a product on stripe's end, how'd i append that product to existing subscription

patent marsh
#

You can update an existing Subscription and add a new line item, for example.

#

Or adjust the quanity of an existing item.

glacial oak
#

figued that, but how does user get notified of that, like that they'd need to pay

#

or how do i notify them

patent marsh
#

Typically the change would result in an off-session payment attempt against their saved payment details for the Subscription. If that doesn't succeed it's up to you how you want to contact them. You can enable failed payment emails in the Dashboard, for example, or you can send your own emails, or contact them in another way.

glacial oak
#

do after i update subscription with new items, it directly charges the user? i got told before this so im just checking #1290662876809527378 message

patent marsh
glacial oak
#

ah so i would need to have proration_behavior to always_invoice before i try updating items

patent marsh
#

proration_behavior isn't a persistent setting on a Subscription, it only applies to the request where you set it.

glacial oak
#

so while updating items

patent marsh
#

Yes.

glacial oak
#

would there be a reliable way to directly fetch that invoice and serve a user with url to it so they can pay

patent marsh
#

Yes, have a look at the latest_invoice property on the Subscription to access the Invoice. You can then verify it's ready to be paid (or update it so it is) then send the customer to its hosted payment page.

glacial oak
#

yup, what webhook even would that be? also update and check for previous or

patent marsh
#

This would be you fetching the data from the API. Not sure what you mean about a webhook in this scenario?

glacial oak
#

uh, my potential confusion is that if i for example downgrade a user, aka modify their items to remove one product they had and add another, that wont create invoice, so basically not on every update will invoice be created and i'd like some way to check when it has been created, i assume i can't directly fetch subscription after i updated it and expect there to be invoice already that fast or?

patent marsh
#

You can.

#

As long as you wait for a response back from the update request the Subscription will then be in the new state. In fact, the response to the update request itself likely has the information you want.

#

Give it a try in test mode and you'll see how it works.

glacial oak
#

will do

teal forgeBOT