morunas-pricing-models

[dreamy flume]

Hey! Let me read through this and get an understanding of what's going on

Answering questions as I come across them:

are there API limitations or number of products I should be aware of?
There's no API limitations for the number of Products/Prices an account can have, no

So if customer A has purchased a subscription on Product Y at $100/year, I need to be able to change the price for Product Y to for example $120/year, without affecting the existing customer subscribed to that product.
I believe (confirming) that any pre-existing subscriptions will be 'grandfathered' in to the Price object at the time of the Subscription creation

Ah, of course. You can't update a Price object once it's been used (i.e. in a Subscription). So yes, you'd have to create a new Price to reflect that change

[supple loom]

Ah so I should keep the same Product, just add a new Price to it. No need to create a new Product (even though the new price is for the same interval as the previous price, just a different amount)

[dreamy flume]

Hmm I believe there might be issues for a Product having multiple Prices of the same recurring interval

[supple loom]

Ya looking at the API here https://stripe.com/docs/api/prices is what made me think that a actual price change would require creating a whole new product

There is an "Update a price" where I can set active to false... not sure if this would:

• keep existing subscriptions with a product with this price running fine
• allow me to add a new price on same interval which can be used for new purchases

The api ref is not complete on this regard I guess :/

[vocal nest]

If you mark a price inactive, it won't effect existing subscriptions using it. However, you won't be able to make new subscriptions with an inactive price

So, you would be able to add a new price on the same interval for new subscriptions

[supple loom]

Ahhh well then this might just do it 😮

So when a Product is created once on our side, it is then created one single time on Stripe with an initial price
If there is a price change for that Product on our side, I mark the existing price as inactive and create a new using the same interval
New subscriptions created on that Product will use the active price
Existing subscriptions on older prices will remain unaffected

Is this correct?

[vocal nest]

Yep

One thing to note, is you explicitly have to specify the new price when creating the new subscriptions

[supple loom]

Sweeeeet :- ) it's a LOT cleaner to have the same list of products across systems...

[supple loom]

Alright, so basically whenever a subscription is created, I pass a single subscription_item on items prop, and that subscription item must have the appropriate price which I can fetch using "List all prices" passing the product the client wants and active: true

[vocal nest]

Yeah that's correct. One thing you might want to do is just store the most recent price ID on your side (env variable, etc.) just so you can reduce the number of calls to the Stripe API

[supple loom]

sure thing 🙂

[vocal nest]

That will speed up your code and reduce the possibility of rate limiting as you scale

[supple loom]

yes, makes sense! I was just temporarily considering potential data integrity / unsynced issues... but I can always add a fallback and when I retrieve the price based on an ID I can check for active:true, otherwise re-fetch the most recent/active

Well I guess this answers all my questions 🙂 you guys rock! Big thanks for the super fast reply ^^

[vocal nest]

No problem!

[supple loom]

Sorry to bother you again, I have one more question: what if I were to also offer "a special subscription" that gives access to all the products? E.g. a customer is subscribed to two individual products, both at $100/year, one product has elapsed 25% and the other one 50% (they have different billing anchors), meaning the customer has $75+$50=$125 left in credit and now they wish to jump to a $1000/year subscription.

I would guess this would only be possible by:

1. Cancel existing subscriptions with "cancel_at_period_end"=false (no proration)
2. Calculate the remainder credit aside
3. Create the new subscription while applying a one time discount for the calculated credit

In other words, since this is not upgrading/downgrading a single subscription... I would assume the proration behavior wouldn't really work.

[vocal nest]

Yeah you're correct again here

If it were just 1 upgrade then you could use proration

But since it's 2 subs, proration isn't coming into play

[supple loom]

ya it's what we've used so far (our current model is just normal single subscription up/down, all products)

[vocal nest]

Gotcha

[supple loom]

Alright, thanks again. Cheers!

[vocal nest]

No problem!