#gl-jkeys_best-practices
frosty aspenBOT
👋 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/1478120803735310510
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
raw hound
hi there, I'm not sure what your question is. is there a specific problem you're having?
final tusk
Hi, sorry I hit the word limitation.
So, the issue is this:
if we sync every day the seat count change in our database to Stripe, and we use send_invoice w/ always_invoice proration behavior, and, say, days_until_due: 30, when will the invoice actually be sent and charged?
If they change seat counts on six days of the month, will we issue six invoices that are due in 30 days from the day the seat count changed?
raw hound
yes, that would be the behavior. the invoice would be sent immediately upon updating the subscription, and your customer would have 30 days to pay the invoice
final tusk
And changing the quantity would issue a prorated invoice for just the seats that were added (or removed)?
raw hound
correct
final tusk
Okay, great. I think that's the ideal behavior from our perspective. I did have one more question: is it possible to backdate an update to a subscription item or an invoice? That way, if we ever decided to invoice, say, once a month, we could still charge for the prorated time for that seat by backdating?
raw hound
yes, you would use the proration_date parameter on your update request: https://docs.stripe.com/billing/subscriptions/backdating?dashboard-or-api=api#backdating-update
but note you can't set that timestamp to before the start of the current billing period of the subscription
final tusk
okay, so in that case, our application would be responsible for tracking the "start time" (and "end time") of each seat, and then issuing one subscription update per start or end time at the end of the month? It's not clear to me from that documentation how I apply that on a per-seat basis.
raw hound
I'm not sure I understand the question. so in the case of, for example, your customer going from 3 seats to 4 two days ago, you would create an update subscription request with a proration_date parameter with a timestamp of 2 days ago, which would cause the update request to act as if the request had been actually made 2 days ago
final tusk
Ah, I'm sorry, I'm thinking of the case where we invoice only at the end of the month, and backdate such that we charge (or refund) for each seat on the day it was added.
so if they from 2 to 3 to 5 to 7 over the course of several days, we would want the final invoice to reflect that there were 2 on day n, 3 on day n+1, 5 on day n+2, and 7 on day n+3.
sorry if that's convoluted
raw hound
oh hmm. that's tricky. let me think about that for a minute
final tusk
I think the behavior we discussed is okay, the only UX problem is that we issue one invoice for each day of the month that their seat count changes.
It would be great if we could achieve the same overall invoicing effect but only do that once per month.
raw hound
something you might consider for this (especially if you anticipate your customers changing seat counts often) is to use Usage Based Billing https://docs.stripe.com/subscriptions/pricing-models/usage-based-pricing#pay-as-you-go
I'm thinking you would send meter events once a day per each of your customers, based on your database, of the amount of seats they're using. it would then automatically bill in arrears (i.e. at the end of the month) based on the usage tracked
final tusk
oh, that sounds perfect and looks better than what we're doing based on a brief scan of that page. So we would use "per unit", update the unit count every day, and then Stripe would do the metering calculation under the hood and automagically invoice the correct amount at the end of the month.
If that understanding is correct, I think that's better than what we've engineered
raw hound
yeah. it's more complicated to setup than standard Stripe subscriptions. but I think it would be a better customer experience than getting lots of invoices. here's an implementation guide, I would recommend testing it out with a sandbox and test clocks https://docs.stripe.com/billing/subscriptions/usage-based/implementation-guide
final tusk
Okay, thanks. I'll take this to my stakeholders and see what they want to do. We might need to live with the many-invoices pattern for now while we work on a migration plan to the usage-based subs.
Thank you very much for your help Denton! (I'm Jeremy at Ginger Labs, by the way 😂 .)
raw hound
you're very welcome Jeremy, glad I could help 🙂