#nukesforbreakfast_best-practices

1 messages · Page 1 of 1 (latest)

abstract masonBOT
#

đź‘‹ 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/1500877404229603502

đź“ť 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.

hidden marten
#

Hi there, looking into this now

dapper shore
#

thanks!

hidden marten
#

Just verifying my understanding here - this is the request that configures the subscription schedule:
https://dashboard.stripe.com/acct_1AvuV7A9yDCrR6n1/test/logs/req_SFnOBFSxbRQpfW

My understanding is that this is setting the end date to when you want it to be cancelled, with end_behavior: cancel along with prorate: false on the phase. This seems to be the suggested workaround from the previous thread:
#1496582370411679754 message

Am I understanding this correctly or is there some part I'm misunderstanding?

dapper shore
#

not exactly. So what I tried was the following:

  1. create schedule from subscription, then modify the phase to end when we wanted with prorate=false/proration_behavior=none. This still caused prorations in the final month.
  2. create schedule from subscription, add a second phase after the first automatically created phase that ends when we want the subscription to end with prorate=false/proration_behavior=none. This still caused prorations in the final month.

What specifically worked was updating the automatically created phase to end on unix_timestamp_we_want_to_cancel_at - 1 and then have the final phase end at unix_timestamp_we_want_to_cancel_at. This seems like a hacky way to do it, so I want to understand why I had to do that and the above 1 and 2 options did not work.

hidden marten
#

Ah, got it. Okay, digging into this now

dapper shore
#

basically making sure this isn't some test clock anomaly that won't actually work in production.

hidden marten
#

Okay, haven't seen anyone use this workaround before, but it does appear valid in terms of its behavior based on my read of the codebase. There shouldn't be any reason why it would only work with a test clock, but you can verify this by doing another test in a sandbox without using a test clock (you can set the end date to be one day in the future)

dapper shore
#

good point! I'll confirm that

#

but do you know why 1 and 2 didn't work even though I set proration to be off?

hidden marten
#

Yeah, this is a limitation with Stripe's proration calculations in general - if you want to cancel a Subscription at a certain date and time that isn't the exact boundary of a billing cycle, this will unfortunately always cause proration with no way to disable it.

Why Approach 1 fails — single phase ending at T:

  • The phase spans one or more natural renewal points (e.g., renews on the 1st of each month)
  • At each renewal, Stripe generates a standard advance billing invoice for the full next period
  • When the schedule cancels at T (mid-period), Stripe issues a proration credit for the unused days from T to the period end
  • proration_behavior: none does nothing here — there was no phase transition proration to suppress; this proration comes from cancellation mid-period

Why Approach 2 fails — two phases, Phase 2 starts at a natural boundary and ends at T:

  • Phase 2 starts at a renewal boundary, so proration_behavior: none has nothing to suppress (no mid-cycle transition happened in any case)
  • Stripe generates the standard renewal invoice at the Phase 2 start for the full billing period
  • When the schedule cancels at T mid-period, same story — proration credit for unused days
  • You're still cancelling mid-period after a full-period invoice was paid
#

My understanding is that your workaround gets arounds this because the 1-second final phase has a negligible billing amount that the cancel_at cancellation produces nothing meaningful.

dapper shore
#

interesting