#chase-subscriptions
1 messages ยท Page 1 of 1 (latest)
Is it a good practice for my platform to maintain exactly one stripe subscription object per customer? thus when the customer purchases new services, my app simply updates that singular api subscription object by adding or removing line items? or should my platform allow customers to manage multiple separate ongoing subscription objects concurrently, for each service?
This is entirely up to you
- if a merchant wants to stop offering a service entirely, and they click "delete" in my app on a whole subscription tier -- how can i use the stripe api to end all active customer subscriptions related to that price/product?
Can you share more on what you mean by "delete" a whole subscription tier?
If you're referring to not offering a particular price/product - Ideally, you should already have saved the list of subscriptions to your database with the price/product ids. You would then want to loop through and delete all active subscriptions related to that price/product
- if a merchant wants to edit a tier's pricing, my app has to inactivate the old stripe price object, and create a new one -- how can my app update the pricing for all the customers' ongoing subscriptions?
Similar to 2. you have to loop through and update the pricing for all the relevant subscriptions
Can you share more on what you mean by "delete" a whole subscription tier?
yes, you've got it -- when a merchant decides to stop offering a service entirely, we'd want to be able to end all the customer subscriptions for that particular service.
You would then want to loop through and delete all active subscriptions related to that price/product
i'm concerned this might become a difficult problem with stripe's rate limiting, say there are thousands of subscriptions, firing off a new api request to update/cancel each subscription could trigger the rate limiting. is there some way to perform api bulk operations? i'm worried if this means i'll have to write some kind of complicated job runner that trickles the operation over a long period of time?
is there any recommended strategy for en-masse api operations like this?
unfortunately, there's currently no way to perform API bulk operations. You'd need to handle rate limiting gracefully, we provide some suggestions here : https://stripe.com/docs/rate-limits#handling-limiting-gracefully
hmm, this could mean that when a merchant edits a price for a subscription, the operation could take minutes, or even hours -- which would mean writing a robust job queue -- and also a sophisticated ui so the merchant can see the progress of that operation ๐ฆ
unless there's some other way worth considering?
sorry to put you in this position brainstorming with me, but i just want to be very certain i'm not missing any alternative, because this would be an immense undertaking.
no worries. There really isn't any other way here that I can think of. I think the general idea is that most merchants wouldn't really update an existing price/product for their customers. They would create a new product/price and apply it to new customers.
If they were to change it for existing customers, they would usually wait till the end of the current billing cycle as an example
okay, help me understand that last point -- if a price is inactivated, will the associated subscriptions expire at the end of their cycle?
and the customer now has to choose manually whether to purchase one of the new active prices?
my bad, i should have been more specific. No the associated subscriptions wouldn't expire at the end of their cycle automatically. The user e.g. you can update all of these subscriptions to cancel at period end : https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at_period_end
right, but then we're back at the rate limiting issue, correct?
yep
okay -- my merchants will be using standard stripe connect accounts -- is there a way for them to perform these kinds of bulk operations from their stripe login dashboard, using the stripe ui?
(i'm just thinking, maybe i can launch these features without the ability for merchants to delete or edit services, and instruct them to use the stripe dashboard for those kinds of changes, until i can implement a sophisticated job runner and progress ui?)
sadly no, there's no such bulk operation to edit multiple subscriptions in the Dashboard. They can edit/delete each subscription one by one, but not in bulk
hmm. i'm wondering, is this a common problem? or am i approaching the modeling here the wrong way?
my instinct is that if a merchant can easily create subscription services for thousands of customers, surely merchants should be able to easily edit or end those subscription services for thousands of customers.
is it more standard, that once a subscription service is established, and thousands of people subscribe, to treat it like it's set in stone?
should a merchant be expected to honor the "grandfathered" pricing, and when a service is ending, simply email all the customers and notify them that they should cancel the subscriptions themselves?
i'm just trying to consider different options here, before finalizing the decision that i have to build this complicated job-queue infrastructure..
(or think of some way to defer that job queue infrastructure to a later version of my app)
honestly, i don't really personally subscribe to any kind of services. But to me, i would expect the merchant to honor the pricing and if they do decide to change, adequate notice should be provided (hence why i mention the cancel at period end)
it's really a business decision at this point
but to answer your question, Stripe doesn't offer bulk edits via the API so all users would have to handle such situations in a way that doesn't hit the rate limit
is stripe support capable of enacting bulk operations like this?
can my merchants request a change like this, and i forward it to stripe support, who perhaps have access to levers and knobs that allow them to bulk-edit subscriptions like this?
no, Stripe Support isn't able to handle such bulk operations like this too.
okay. do the rate limits (100 requests per second) apply to each individual stripe connect account (each merchant), or the whole platform's stripe account?
hmmm, onesec, let me just check to make sure that i'm giving you the right info
thanks so much, i really appreciate it, sorry to send you down the rabbit hole like this.
are you making the requests to edit these subscriptions on behalf of the connected account i.e. using the Stripe-Account header? https://stripe.com/docs/connect/authentication
yes, that is correct
sorry, but i don't really have an answer for you right now, if you don't mind writing in to Stripe Support, i'll grab your ticket and get back to you tomorrow?
okay, understandable, thanks for trying for me.
to wrap this up, here's my current plan:
- launch my app's subscription system for merchants without the capability to edit pricing or end services. i can get away with that for a few months, maybe handle situations manually by writing scripts whenever a merchant needs a change.
- write a robust job-queue, with a pretty ui, to handle bulk operations like these -- and launch the feature later down the road. i'll make it open source so that anybody in the same situation might benefit in the future ๐
-- and referring all the way back to my first post -- i think i'll proceed with my plan to maintain at most one active subscription object per customer, updating it's line items in accordance to whatever services the customer wants to add or remove.
yep makes sense. After you reach out to Stripe Support, let me know your account id so that i can find your support ticket.
okay thanks so much for your help alex.
i'm going to head off now, cheers ๐ป