#oboxodo
1 messages ยท Page 1 of 1 (latest)
HI ๐
That's a lot of text, give me a sec
๐
I tried to explain with the least text possible, heh
I'm open to clarify whatever you need. I'll wait for your questions.
I'm a little confused here. Have you tested this out?
Each Price object is directly linked to a specified Product object. So you should not be able to apply a Price from Product A to Product B in any situation
Sure a user can update the Price from a Price for Product A to a Price for Product B, but that would show up as a change from Product A to Product B
hey.
yes. That last situation you're mentioning is what we want to forbid.
If a user has a subscription for Product A, and a subscription for Product B, I don't want them to be able to change theis subscription for Product A for a new subscription on Product B, ending up having 2 Product B subscriptions.
do I explain myself?
๐
Actually... it's a bit more complicated than that... let me see if I can explain further...
I think I understand overall
And unfortunately don't think this is possible for the Customer Portal to really handle
For this to be handled you would need to determine up front what Price the Customer is going to update to/from for the Customer Portal and then only pass a configuration that allows for that
Which is a bit of a pain
We have 4 products in Stripe: A, B, C, and D.
Products A, B, and C, have 2 prices each and they're, let's say... "compatible" between them. Meaning if I have a subscription on any of those 6 prices, I should be able to change to any of the other 5.
But, Product D works independently from the other 3 and has 2 prices too, but a subscription on any of these 2 prices shouldn't be changed for any of the other products' prices.
I'm fine having 2 configurations, one limiting to the 6 prices for products A, B, and C. And another for the 2 prices on D. That works perfectly when a customer has either a subscription on A/B/C or D. The problem is when the customer has both subscriptions at once.
Yeah don't think Customer Portal really handles this well unfortunately
Right I understand
The only way to really handle this would be to actually have separate Customer objects
But that is a huge pain because then you need to collect Payment Method details twice
The perfect solution for me would be to create a portal session specifying what subscription it is for, so the user is not given the option to pick which of the 2.
I see I can only specify a subscriptioin when the flow is for canceling the subscription ๐ฆ
but it's soooo close to working like I wish
Yeah this is great feedback and something I will pass along to our Customer Portal team
Yeah this just isn't going to be possible today with Customer Portal. The best I can do is to submit a feature request to get a specific Subscription parameter added to the update config
Here you have something you can attach to that feature request:
or, simply allow specifying which configuration id to use for each of the existing subscriptions
Yep makes total sense.