#checahgo_api
timid juncoBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1248269528824021083
đ Have more to share? Add details, code, screenshots, videos, etc. below.
sudden trout
Hi! I am following up with this issue from my boss yesterday.
We have a enterprise account managing subscriptions that are all unique schedules and instances. They are creating the subscriptions for their clients.
devout needle
It seems like the subscription is what drives the schedule, and they are all annual subscriptions but are created the day they take an action
subscription_item in the docs looks like maybe we could add them, but then the timing seems to be an issue.
what is best practice for Stripe's clients for handling many subscriptions for single 'customers'?
grave spoke
Mostly you group items as much as possible
If you really have to then you create multiple Customers
devout needle
by group do you mean adding sub items under a parent schedule?
grave spoke
But this would mean needing to gather multiple instances of their payment method when you collect their payment method
Yes, adding multiple items to one Sub
devout needle
would doing a sub for every day work? then we just add it if one already exists?
trying to figure out the best/cleanest way for this. multi customers is def something i want to avoid
so we'd have 365 subs (if a customer used every day), then add any multi items if that day already exists
trying to make sure we have the best approach on this. And do the charges come through at the sub or item level for a day if multiple exist?
and invoices single or multiple?
grave spoke
Yeah one for each day sounds like it would work for you.
Subscriptions always generate a single Invoice each time they renew
The best thing to do is test this all out in test mode
And use test clocks: https://docs.stripe.com/billing/testing/test-clocks
devout needle
anything else we should consider you can think of?
grave spoke
Mostly you want to ensure you are handling upgrades/downgrades and proration as you so desire
To figure that out will mostly involve testing the different flows your customers will have access to.
devout needle
Is there a cap on subscription_items?
grave spoke
Yes, 20 is the default limit for Subscription Items
timid juncoBOT
devout needle
How do we handle our needs then? because we could have potentially thousands of subscriptions needed, and if items limit at 20, then our daily approach won't work either
mystic sparrow
20 subscription items and 500 subscriptions per customer is a hard limit, so you'd need to create multiple customers then
devout needle
How do other clients deal with these limits?
mystic sparrow
It's generally a rare need to have > 500 subscriptions with > 20 line items per customer
devout needle
interesting. We could get by if we had the 10K subscriptions, but the schedule on the parent becomes the issue then. Is there a way to deal with the billing occurence schedule by item, or some other way we can handle that?
i.e. our approach mentioned earlier on tihs ticket would assume we use each 'day' as a parent subscription, but then the 20 cap bites us.
mystic sparrow
Not sure I fully understand your use-case, but another thing you could consider doing is just creating a brand new customer for each subscription
devout needle
Or is using a qty on a sub_item work? So if we had 500 subscriptions in a day, we could create 1-Sub, 1-SubItem and that Sub-Item would have qty 500.
Then comes the metadata, can we add as many key-values as we want for metadata?
The sub_item is the same price_id or Product, but we have to track a lot of occurances that each tie back to an 'entity' in our app.
mystic sparrow
There's a 50 key limit for metadata: https://docs.stripe.com/api/metadata
You could just store this data in your database though instead of metadata in Stripe
devout needle
does the qty idea work in your mind?
mystic sparrow
Yeah there's not a limit on quantity as far as I'm aware
As long as the total is under our maximum charge
devout needle
whats the max charge?
and is there a list of the max caps like these things we are running into?
devout needle
so to summarize caps so far:
500 subs
20 sub_items/sub
50 key limit for metadata
99,999.99 for charge
Could you confirm qty cap?