#skammerens-datter_api

1 messages · Page 1 of 1 (latest)

mossy houndBOT
#

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

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

twin sirenBOT
#

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.

zealous harness
heavy copper
#

👋 happy to help

zealous harness
#

hi tarzan, great 😄 not sure if my link works properly, but I just had a thread that I unfortunately lost that is referenced above 19 minutes ago

heavy copper
heavy copper
zealous harness
#

can i pass the proration_date when updating the subscription as the unix timestamp from a property of the current subscriptions cycle? i am not sure if such a property exists, what it'd be named, or if i should perform math somehow to determine when the subscription ends...

#

i want to ensure that the subscription's product is only changed (if downgrade) when the current cycle is over. Upgrades should be instant, like they are working in my integration now per the previous thread

heavy copper
#

can i pass the proration_date when updating the subscription as the unix timestamp from a property of the current subscriptions cycle?
yes any timestamp work (it needs to be in seconds not milliseconds)

heavy copper
zealous harness
#

could you elaborate? 🙂

heavy copper
#

yes give me a second I'll share the exact doc

zealous harness
#

thank you

heavy copper
zealous harness
#

thank you, I'll read it and do my best to implement it 🙂

heavy copper
#

let me know if you need any more help

mossy houndBOT
zealous harness
#

i am implementing it now, but i have another question. If i wish to upgrade a subscription, how can i charge the proration immediately rather than on the upcoming invoice?

vapid dagger
#

you would pass proration_behavior:"always_invoice"

zealous harness
#

thank you

#

would it then invoice the proration plus the next month, or just the proration? with the current behaviour it adds the proration to the upcoming invoice and naturally also the subscription price of that month. if it were to invoice immediately, it just only be the proration, so that next month's invoice is the new price without the proration

vapid dagger
#

it's just for the proration amounts

zealous harness
#

okay, noted 😄

#

when I create the subscription schedule, if the customer chooses to downgrade, will no product change be made, and i instead listen on a webhook to downgrade them when stripe runs the schedule phase change?

vapid dagger
#

I don't really understand the question. The point of using a Schedule is it makes change to the Subscription automatically at times indicated by the phases you pass.

mossy houndBOT
zealous harness
vapid dagger
#

in that specific example yes, since the code is creating a second phase that starts at the end of the current phase(which is aligned with the current billing period), and that phase changes the subscription item to use the new Price PRICE_PRINT_BASIC

#

I'd suggest testing all this in test mode with TestClocks to see how it works in practise

zealous harness
#

thank you once again