#chase-subscriptions

1 messages ยท Page 1 of 1 (latest)

oblique apex
#

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

  1. 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

  1. 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

winter tangle
#

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?

oblique apex
winter tangle
#

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.

oblique apex
#

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

winter tangle
#

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?

oblique apex
winter tangle
#

right, but then we're back at the rate limiting issue, correct?

oblique apex
#

yep

winter tangle
#

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?)

oblique apex
#

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

winter tangle
#

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)

oblique apex
#

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

winter tangle
#

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?

oblique apex
#

no, Stripe Support isn't able to handle such bulk operations like this too.

winter tangle
#

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?

oblique apex
#

hmmm, onesec, let me just check to make sure that i'm giving you the right info

winter tangle
#

thanks so much, i really appreciate it, sorry to send you down the rabbit hole like this.

oblique apex
winter tangle
#

yes, that is correct

oblique apex
#

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?

winter tangle
#

okay, understandable, thanks for trying for me.

#

to wrap this up, here's my current plan:

  1. 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.
  2. 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.

oblique apex
#

yep makes sense. After you reach out to Stripe Support, let me know your account id so that i can find your support ticket.

winter tangle
#

okay thanks so much for your help alex.
i'm going to head off now, cheers ๐Ÿป

oblique apex
#

got it

#

deleted it so that your email isn't left on a public channel