#leocybsec_best-practices
1 messages ¡ Page 1 of 1 (latest)
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1380187906529955851
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi, why are you creating these prices dynamically? What is your use case? It is recommended that you create a Product and Prices in advance and re-use them if the amounts are the same.
As for updating the customer, you can't use the CheckoutSessions however, we have a separate product called Customer Portal, https://docs.stripe.com/customer-management/integrate-customer-portal that helps with subscription management
You can configure it to only update the subscription with a subset of products that you choose
You can also use it to collect new payment method details
Please let us know what questions you may have after reviewing the document
As i read in documentation, first of all we need to create a product. Then we creating a price and assigning product to price. After that we creating a subscription with this price. In my case for each user price of subscription will be different cuz price calculating dynamically so i cant predict in any cases what price will be.
For my case what will be the best practice?
As you scale, you might see issues with rate limiting: https://docs.stripe.com/rate-limits is what I worry.
Can these dynamic prices be grouped?
I can only group them by level of subscriptions(Premium, Starter, Premium). So i created such products like on screenshot, is it group?
No, I more meant grouping the prices
Sorry, i didnt get, by what factors we can group prices? By price?
Taking a step back, your approach of ad-hoc price_data is fine if you need custom pricing for each customer. If you have re-usable prices, it is better to create those fixed Price objects and re-use them for applicable sessions.
Is it any way to make like checkout page but for the subscription update, to trigger user to submit the new price for package on stripe side?
Partly, you can use the customer portal as pgskc indicated: https://docs.stripe.com/customer-management
In particular, you can use deep link flows to have your customer confirm a specific change to a subscription, such as appliying a new price to exisitng items: https://docs.stripe.com/customer-management/portal-deep-links#what-is-a-flow
So u suggesting to use customer portal for my case? To traspose all logic to portal?
No, I'm saying the portal could support the flow you asked about here:
Is it any way to make like checkout page but for the subscription update, to trigger user to submit the new price for package on stripe side?
The subscription update/confirm deep flow might be a good fit for that for you, but you need to test it
Notably, the portal cannot currently be used to create new subsriptions, only manage existing ones.
So for any flows that sign up new customers or add more subscriptions to customers, you need to address that another way (checkout, custom code etc).
Okay so as i correclty understood.
With customer portal i can handle all subscription events(upgrade, downgrade)
But for creating subscription i need to make a checkout.
But i still do not get about what better will fit to my case.
I have 3 different subscriptions, they have dynamic price.
When the user wants to upgrade his subscription, he will needs to fill new data what will be taken to calculate a new subscription price. With portal can i implement such logic or it only works with presets of prices?
In my case that the best practice will be?
In that case you'd like need your own UI to collect those details that determine the price, then you create the price and set them to the customer portal using the deeplink flow with that new price to confirm the change.
Like this one?
Yea, you could use that with your new customer-specific price bsased on the details you collected from them first