#oboxodo

1 messages ยท Page 1 of 1 (latest)

tranquil lionBOT
vale path
#

HI ๐Ÿ‘‹

That's a lot of text, give me a sec

boreal leaf
#

๐Ÿ™‚

#

I tried to explain with the least text possible, heh

#

I'm open to clarify whatever you need. I'll wait for your questions.

vale path
#

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

boreal leaf
#

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?

clever steeple
#

๐Ÿ‘‹ stepping in as Snufkin needed to step away

#

Catching up

boreal leaf
#

๐Ÿ‘‹

#

Actually... it's a bit more complicated than that... let me see if I can explain further...

clever steeple
#

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

boreal leaf
#

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.

clever steeple
#

Oh wait

#

Ah nvm

#

Hmmm

boreal leaf
clever steeple
#

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

boreal leaf
#

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

clever steeple
#

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

boreal leaf
#

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

clever steeple
#

Yep makes total sense.