#bark-billing-arrears
fading field
Unfortunately not, our usage based subscriptions bill at the end of the month but there is not a way to get other subscription types to bill at the end of the month https://stripe.com/docs/billing/subscriptions/usage-based
hushed crater
hmmm that is unfortunate.
Usage based-billing isn't really appropriate in this case, as it's straight-ahead monthly.
I notice that when you update a subscription, e.g., to add a new item or update quantities, you can prorate that change and it'll be billed at the next invoice—technically the end of the current period. But what happens when you take something out mid-cycle? Since the invoice for that was in advance, there's no way to lower that cost accordingly.
fading field
Using the same proration settings that would credit the customer and take money off of their next invoice. You can do a partial refund if you want with additional API calls
hushed crater
Ah I see. Thx much.
I will have to ask the company if they are OK with billing their customers in advance. If not, then perhaps we can set up something like metered usage—just setting the usage to '1' every month I guess—but in that case we'd have to handle the proration ourselves, correct?
dry radishBOT
drowsy oracle
yes
you can also use collection_method: 'send_invoice' and give them 30 days to pay for example, it's common for B2B: https://stripe.com/docs/billing/collection-method
bark-billing-arrears
hushed crater
I'll look into that but the documention is not completely clear to me.
Assuming a monthly billing, the invoice will still be automatically generated, but not automatically sent...is that correct?
drowsy oracle
generated and sent upfront but not "charged" until the due date (they can pay via wire transfers or on the hosted invoice page, etc.)
hushed crater
Yeah, that's still not what they want. What they want is for the invoice to bill for the period which has just ended and not include any future charges. Giving the customer time to pay is nice, but if the invoice is generated up front it might no longer be up-to-date by the end.
drowsy oracle
yep I get it, it's definitely a common ask, just not something we support 😦
hushed crater
Would it be difficult to implement using metered usage? I know that is generally used for things like timed usage or daily, but would that work for monthly charges?
drowsy oracle
no that shouldn't be too hard, but you do lose all benefits of proration like you said
hushed crater
Agreed. I will have to ask our fearless leader which poison he prefers. We have to take action if a customer wants a change anyway.
In this case, would the usage then be "1" for a full month and some fraction for a partial? I assume we'd want to use aggregate_usage=last_ever
?
hushed crater
Hmmmm....without a fraction how could we make montly rate work with metering?
drowsy oracle
not sure I understand what those words mean
Can you give a concrete example of who pays what when? If you have a $10/month Price then you put quantity 1 (or 1 UsageRecord) and then it charges $10
hushed crater
Sure. Suppose it's $10/month and the user wants 4 of them. Then on day 20, they drop down to 3. At the end of the month we want to charge them for (0.33) * 3 + (0.66) * 4 items, because they had 4 for 2/3 of the time and 3 for 1/3.
drowsy oracle
None of that is possible at all with metered billing that's what we were explaining. This is just impossible.
So instead you calculate all the proration yourself and create one-off InvoiceItems that get pulled into their next Invoice
hushed crater
Understood. Thanks for your help.