#nukesforbreakfast_best-practices

1 messages ¡ Page 1 of 1 (latest)

umbral sleetBOT
#

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

📝 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.

summer helm
#

I'm not clear on how to backdate the change to the beginning of the subscription schedule to ensure either:

  • If the price goes up, that all uncollected amounts that should have been collected get billed for
  • If the price goes down, that all credits are given since the very beginning of the subscription
cunning field
#

That's how proration should work. When you Update the Subscription Schedule, keep this proration_behavior as create_prorations (default)

summer helm
#

ok, but is there a field to date when the subscription change should have occurred?

#

would that be the phase.start_date?

#

In case of this occurring, it would be a mistake and the change to the permit type would come after the subscription has already billed and potentially paid for.

cunning field
#

Hmm I am afraid that's not possible. In the API you can't "change the past". You can only change the SubSchedule's phase which hasn't occurred.

Let's say if you SubSchedule has run from 2025 Sep 1, phase 0 to 2026 Sep 1. Today is 2025 Sep 10. You can make an Update call today to change the Price of the rest (until 2026 Sep 1), but you can't change the starting time (2025 Sep 1)

#

You can give it a try using our Billing Test Clock

summer helm
#

so you can't automatically backdate a proration.

#

like say "change this subscription's price effective <some date in the past>"

#

for simplicity let's assume no subscription schedule is invovled and it's a regular subscription

cunning field
#

Seems possible only in the first period

summer helm
#

and I just want to backdate a price change on that subscription to some date in the past. Say the subscription started on 2025 Sep1 at price $50 but it's now 2025 Oct 1 and I need it to be at price $25 as of the original subscription start date.

summer helm
#

but this is for subscriptions. The question is what happens if that subscription is controlled by a subscription schedule.

cunning field
#

I think it should still be possible, but please test it out. Use our Billing Test Clock. You can simulate time advances

summer helm
#

yeah, so if in the first year we realize it's wrong, we can backdate it to the subscription start and it would do as we expect. If we only notice the second year, we would have to manually do something for the first year.

cunning field
#

we would have to manually do something for the first year.
Yes, like give your customer some credit note or generate an one-off Invoice accounting for the diff

summer helm
#

Alright.

#

How do I update the currently active phase of a subscription schedule?

cunning field
#

Yes

summer helm
#

ok. I will do some tests on this changing and see what happens using test clocks.

summer helm
#

I've noticed a decent amount of latency when creating test connected accounts in my test sandbox

#

is the v1/accounts endpoint expected to take seconds to respond when creating a new account?

#

req_ZEHFRXatHVkNMT