#Dharunkumar Natarajan-metered
1 messages · Page 1 of 1 (latest)
Hello! Starting up a thread for you
If the price you're working with has aggregate_usage: sum then we allow for additional 5 minutes to account for clock drift (we talk about this here https://stripe.com/docs/billing/subscriptions/usage-based#report), but if you're not using aggregate_usage: sum then there isn't a way to report usage retroactively
Dharunkumar Natarajan-metered
I am using aggregate_usage: sum but what if within the 5 minutes duration, my background jobs will not be able to complete the computations and report the usage? Any suggestions for this case?
There isn't any good way to retroactively correct the usage of a billing cycle that has already passed/ended - the only other solution I could think of would be to shift the billing cycle to be a few mi nutes in the future (so that you report usage for midnight Oct 1 - midnight Nov 1, but the Stripe billing cycle is for somethig like 1 AM oct - 1 am Nov 1). Does that make sense?
that makes sense, but if the no.of customers signing up for my product increases, the background job will be taking more time to report the usage, in which case I would have to shift the billing cycle again?
Instead of reporting usage all at the end, can you report usage in batches to minimize the amount of time it takes at the end of the period?
yeah, I am already doing that by reporting usage every 6 hours
but just thinking about the scalability
Is the issue that you have to calcualte usage for all your subs at the start of the month? (I assume they all have the same billing cycle?)
Sorry for late reply, but to continue the conversation:
yeah right, all my customers will have the same billing cycle
Yeah the only other thing I can think of is to have a large delay or maybe stagger your subscriptions so they don't end all at the exact same time