#msms-subscriptions
void gulch
@fiery slate hi! I would have said just creating a new price and changing to it, yes (https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#changing).
The fact it might lead to having extra Price objects is just somewhat unavoidable. You can mitigate a bit by reusing them or constraining what these offers can be (so they you have a smaller pool of Prices to pick from and not create new ones bespoke for each case).
fiery slate
hi @void gulch thank you for your answer!
what you say makes sense. It seems to be the only sensible way of allow price changes within the environment of Subscription API, as I dont want to handle all the complexities of invoicing, bill cycles etc myself.
We will probably limit price changes to 1 or 2 times a month.
void gulch
for completeness the other way to do this is to use invoice items, stuff like https://stripe.com/docs/billing/invoices/subscription#adding-upcoming-invoice-items , so you can modify the next invoice of a subscription by adding (or subtracting) some amount dynamically. But it's not really the same as changing the recurring base price(you have to change the Price for that)
fiery slate
I see
I have a question
Let's say I have the following situation:
- sub providers create a product with price A
- 100 users subscribe to that product
- after 2 weeks sub providers decides to change price of the product to price B
- 100 new users subscribe to that product
- I want the old users, at the next cycle, to be billed the new price B
- I want the new users, at the current cycle, to be billed the new price B
how can I do that with Subscription API?
I think I would have to keep price A and price B as active: true
then I would have to wait until all old users no longer use price A in order to set price A as active: false
is that correct?
void gulch
want the old users, at the next cycle, to be billed the new price B
you have to change the 100 existing subscriptions to use B instead(the API call at https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#changing for each one)
making it happen on the next cycle is tricky unfortunately. Technically they are on B immediately from the time you make that change API call. By default on their next billing cycle they pay the price of B, plus a prorated amount of B from the time of the update to that time, minus a prorated amount of A for the same period. (but you can disable the proration if you don't want that)
you can set A to active:false whenever you want, it just stops you using it for new subscriptions, existing ones are completely unaffected by flipping it
fiery slate
from a time complexity point of view it seems to be quite inefficient - imagine a popular user with 100k subs.
if I were to implement it I would probably have to make a job queue or something in order to change the price of so many users. and the timing problem as you mentioned will cause weird invoices sometimes.
is there another way in your opinion?
I am thinking - what if instead of creating new prices and changing the subscription of a huge number of users, I create a price of 1 cent (or whatever unit in the lowest denomination of a currency) and vary the quantity instead?
Would that give weird-looking invoices to users? something like
invoice for a subscription of price 0.01 USD of qty 200
void gulch
from a time complexity point of view it seems to be quite inefficient - imagine ...
there isn't really another way at the moment, though this type of bulk switching of one Price to another is definitely something we want to make a lot better in the future and have various plans around. Right now it requires a bulk script/action on your side.
now the other thing you mention, is kind of an option too and was going to be another thing I suggested. You can create a Price with a certain unit amount and vary the quantity. But yes, the invoice line items will look like what you say there.
You could also use a $0 price(just so the subscription exists and recurs), and each month, add an invoice item(https://stripe.com/docs/billing/invoices/subscription#adding-draft-invoice-items) for the "real amount", where presumably you pull that from your database somehow(like get a webhook from us that the invoice is created, check your system for what price that person charges, and add the item).
fiery slate
if I understand your $0 price correctly, the following would roughly occur
- bill cycle about to end, needs to be renewed
- stripe creates a draft invoice and sends
invoice.createdwebhook event - in my webhook code, I make sure to set the correct price for the subscription of that particular user on the invoice as an invoice item
- I call the stripe api to finalize the invoice
- Stripe will attempt to charge the user's card automatically
is that more or less the flow?
void gulch
you don't have to finalize the invoice, just create the item, the invoice will get automatically finalised after an hour
but yes, the rest is correct
fiery slate
thank you so much, it seems to be a nice workaround!