#ferbeab-portal-configuration
1 messages ยท Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- ferbeab, 3 hours ago, 4 messages
Is it possible to define not only to which plans the user can update, but which plans are updatable in the first place?
You can do this by product id: https://stripe.com/docs/api/customer_portal/configurations/create#create_portal_configuration-features-subscription_update-products-product
You define which products can be updated to which prices
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
You unfortunately can't get more specific than that though
That would be enough, but it allows any active subscription (even if not listed in features.subscription_update.products) to be updated. So, that field is only defining the products that the user can update his/her active subscriptions to. But, it doesn't avoid to update any other subscription that might be active
Hm that doesn't seem right to me
This is what the field is supposed to be for
Can you share the customer portal session id where a subscription with a product not in your configuration was allowed to be updated?
Yes, sure
It allows to update a subscription with productID prod_P8fMl8uRA17fmG while in the portal configuration only product prod_OgURagaR4R0ru9 is set as updatable
Do you have the session id?
Starts with bps_
Or the request id used to create the session?
Let me check, because I created it with the default_login page
bps_1OL5y0CuoqT4MVmxjB83yNTl
That one is the session id: bps_1OL5y0CuoqT4MVmxjB83yNTl
Thanks, I'll stay tuned!
Hi ๐
I'm stepping in as my colleague needs to go
After some research we've determined you need to explicitly specify the prices for each product that you will allow the Customer to modify. For example
[
{
prices: [price_a_for_prod_y, price_b_for_prod_y],
product: 'prod_y'
}, {..}
]
We recommend you create a new portal configuration and test this with a new portal session
Hi, thanks again. I believe I am already doing that. It is a pitty that is not included in the response when the portal configuration is retrieved, so that we could confirm. But I attach a picture where you can see I am defining the product and price ids. But it is still allowing to update active subscriptions with a different productId
Sorry the picture is not very helpful. Can you provide the request ID where you create the portal configuration?
The portal configuration id is bpc_1OL5eVCuoqT4MVmxKfnCcTIZ, just in case you can check in your end
It will start with req_
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Here it is: req_hiQpm7AUMusvcW
Thank you
And when you create a Portal Session with this configuration, you are able to select more prices that just these two?
No, but I am able to modify other active subscriptions into these prices. This is unintended because the customer might have other active subscriptions that are completely unrelated
Okay, thank you. That clarifies things a bit for me
Do you have an example of such an update?
Of course, I have two subscriptions. Sub_A is the base subscription to my service, currently users can update the billing frequency and in the future they will be able to subscribe to more advance plans.
Sub_B is a subscription that grants the user extra cloud storage and he can select different plans with increasing quota.
In the portal configuration we are discussing I am limiting updates only between sub_A prices. But the user is able to also update sub_B into sub_A. In this case he ends up with 2 base subscriptions and lose the entitlement to extra storage.
It is unintended that one user can hold 2 different base subscriptions simultaneously. I block it in my side, but it can happen through this loophole. Aside of it being very confusing for the user
I can understand that. I'm reaching out to a colleague (it's kinda busy on the server so I haven't been able to test this).
@distant fractal do you mean you are busy to look into it today, or that it is not implemented?
Sorry, I mean this feature is not supported. There's no way to configure the CustomerPortal to allow Price upgrade per Subscription unfortunately so the flow you are trying to achieve is not possible
Ok, thanks. Any recommendation for this case?