eblackey_api

[left musk]

👋 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/1473326038695018609

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

[vale agate]

Hey there, canceled_at is set immediately when using the cancel_at_period_end parameter like you've done here, which is why it gets set for this API cancellation:
https://dashboard.stripe.com/acct_1DiMkgERMQSPMq1W/logs/req_gewcmgVeKaMzPP

For the portal, this uses cancel_at internally instead, not cancel_at_period_end, even if it targets the same end date.

Can you explain you end goal and how this is affecting your integration?

[novel valve]

It's downstream reporting that it's affecting. We switched to the Billing Portal last fall and they're now seeing the impact of that change in their numbers. So not really an integration problem, but I was more curious of why there was a difference between the two.

[vale agate]

That's really down to an implementation detail, which is why i'm curious to know how this is being used in the integration such that it makes a difference

[novel valve]

Yeah I think they were looking at reporting on how many days before a subscription trial ends did the cancellation occur. They were able to use "canceled_at" previously because it was being set to the time that the customer initiated the cancellation, but now canceled_at is not set until the subscription end date (or trial end date).

My recommendation to them was to listen for subscription updated events when a cancellation occurred and then set metadata on the subscription. I couldn't think of a better option.

[vale agate]

So for the portal subscriptions, you can listen for customer.subscription.updated events like evt_1SoX6PERMQSPMq1WlwuqvJU4 and check when cancel_at is set (this is what the portal does)