#harry_api
stray oracleBOT
👋 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/1351673453710934117
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
crimson prawn
I know that I could add device IDs to the subscription (with qty of 2) to the subscription item meta data, but that feels messy. I am open to doing this a different way but do not see why it shouldnt be possible to add the same product/price_id to a single subscription. Appricate anyone that can shed some light on this
distant rune
Hi! Can you share the Request ID with the error?
distant rune
Awesome. One sec.
crimson prawn
tyty
So essentially, previously I would upodate the QTY. But I would like to be able to add the same product/price_id to the existing subscription (think customer owns one Device License, then wants to purchase another) I can increase the QTY on the existing subscription line but would rather have it completely seperate so that I can associate the Device record directly with a subscription item, let me know if I didnt explain that clearly
stray oracleBOT
crimson prawn
Hey Solanum 🙂
crimson prawn
okay ty, let me know of any questions
plush lodge
ok, i get the "what" of your question... ultimately this feels like a feature request to me, so i think i need to work on understanding the "why." i think you've already identified the current recommended solution which is updating the quantity for the existing line item.
can you explain what you mean by "associate the Device record directly with a subscription item"?
crimson prawn
okay so
in my app I have a devices table, devices are only allowed via a license. If I were to just use the QTY method, I would have to just have an array if device.ids in the meta data of the subscription (containing qty 2). In my database I have subscription items as screenshotted
ideally I would like to be able to have numerous rows for each device, as a seperate subscription item, so then in my devices table I can say, this device is paid for and subscribed via this specific stripe id
so then I would have a granular record of, this device was initally subscribed at this date etc
sorry its late here so I might not be explaining clearly
plush lodge
nah i think i get the gist of it... thinking through solutions here and yeah i think the (messy) metadata option is probably the best thing i can think of as well. let me noodle on it for a bit though.
crimson prawn
okay thanks
I'm not sure if I am missing a piece of context on how stripe works, I just dont see why I cant add the same price_id to the same subscription you know?
From my understanding a price_id is just a set price data object for a product, you could have multiple prices for the same product for numerous reasons
and therefor should just be able to add the same price_id as many times as you want to a subscription
plush lodge
yep! a common use case for that would be having a subscription model with annual pricing vs monthly pricing.
unfortunately i can't speak to the why of us limiting you to using the quantity to adjust the count vs letting you specify them multiple times, would probably need to do some historical spelunking to figure that out.
crimson prawn
I think thats what is most jarring to me
like its making me feel like I am doing something wrong by even attempting it
when in my opinion it seems the most logical way of setting it up
plush lodge
ok i'm struggling to come up with any great solutions to this. bad ideas only time: create a new price per device 😛
plush lodge
technically that would work, i double checked and we don't limit the number of prices you can make. but there would probably be unintended consequences that i'm not thinking of now.
crimson prawn
yeah not gunna lie that sounds less than ideal haha
plush lodge
yeah i agree
i'm in brainstorming mode 😛
ultimately your goal here is to be able to disambiguate the devices when you're checking against their subscription status in stripe, right? am i getting that part correct?
crimson prawn
yeah exactly
like say we sell devices at 12 month minimum span
just updating the qty means a device they started paying for 3 months ago is now mixed in with a new device they just purchased a license for
unless I add a tonne of metadata
plush lodge
any chance you have an existing subscription handy i can look at? i wanna see how you're structuring things currently
one other thought is you could just have a separate subscription per device rather than trying to manage them all as items on a single subscription
crimson prawn
this is all local dev atm let me see if I can find a subscription id
issue with seperate subscriptions is that it would then be different billing dates, seperate payments etc right?
plush lodge
yep that would be a side effect of that approach, yes
crimson prawn
does this help?
sub_1R3y9HJ6I7CpoajDXhbIW8yD
here is one with multiple POS licenses (20)
sub_1R3lFsJ6I7CpoajDY78Nh9jH
brb
Back
plush lodge
still thinking / poking around at things
i might run this by some colleagues to get their thoughts
crimson prawn
Okay sounds good 👍
plush lodge
ok i'm running this by a colleague and they are on team "make a new price per device" as being the best option currently available. one other thought is it includes the lookup_key which you could use to store the device id, and then the price could be pretty easily looked up and re-used in the future if for instance one customer cancels and you transfer the device to another
https://docs.stripe.com/api/prices/object#price_object-lookup_key
stray oracleBOT