#supay_api
hushed magnetBOT
👋 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/1408119592663908413
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
prime axle
You are currently using the Customer Portal to allow users to change their seats?
tight sleet
No we are using the Stripe SDK
prime axle
how are you currently handling this? Do you have a code snippet you can share?
If the invoice is not finalized you can simply make an update call on the draft invoice.
tight sleet
Yes, we are doing this.stripe.subscriptions.update({subscription:{items:[...]}})
I saw documentation about it https://docs.stripe.com/billing/invoices/subscription#adding-draft-invoice-items
But the documentation is not clear
prime axle
I believe if the invoice is stillin a draft state it shouldn't create a new one? Are you getting an error when you update the subscription?
tight sleet
I’m not getting an error. Instead of updating the draft invoice, it create a second one
Since its a prorated price could it be the issue ?
prime axle
and the prior draft is not being voided? (trying to test this now but juggling a few other threads, I appreciate your patience)
The emails shouldn't be sent until finalization
tight sleet
Exactly the previous invoice are not being void
Emails are not sent since there are still in draft. But if the user add seats at 5 different time in the span of an hour, they get 5 emails instead of hopefully 1
hushed magnetBOT
gloomy tinsel
hi! fyi i am taking over this thread. any chance you have an example subscription i can take a look at to see exactly what you're doing?
gloomy tinsel
the default behavior here is to create prorations which would be picked up on the next invoice created. are you setting the proration behavior to send invoice?
tight sleet
Yes we are using proration_behavior: always_invoice. The issue with create_prorations is that is won't charge the customer until the next billing cycle.
Is there a config to change this behavior ?
gloomy tinsel
any time you update the subscription it will create the prorations immediately, and you can either invoice right away (what you're doing) or generate the prorations to be picked up by a later invoice
what i would consider doing in your case is do the updates with create_prorations, then create a manual invoice for the subscription when you're ready to actually charge them
that way you can have control over when the invoice is created and sent, and you can charge without waiting for the next billing cycle