#barbud_best-practices
dark turtleBOT
đź‘‹ 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/1396855795114840164
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
rigid granite
Hi, that is not supported: https://docs.stripe.com/payments/checkout/pricing-table. You will need to build that on your end
crisp tinsel
I see it says this :
Business models—The pricing table supports subscription business models such as flat-rate, per-seat, tiered pricing, and trials. It doesn’t support usage-based pricing models.
rigid granite
That is correct. You can use https://docs.stripe.com/billing/subscriptions/usage-based integration flow instead.
dark turtleBOT
crisp tinsel
Oh ok so I can’t use the pricing table and customer dashboard anymore? Previously I used pricing tables to create the stripe account and then I go through hosted onboarding, and now I would have to code the pricing table myself and have the user pick a plan and make api call? Also I need to handle the customer subscription changes upgrade/downgrade and cancellations on my own or will there still be a customer dashboard?
rigid granite
No, you can still use the Customer Portal but you'd want to use https://docs.stripe.com/billing/subscriptions/usage-based for your integration flow.
crisp tinsel
Ok so can I still keep my pricing table for signing up to the plans and then use metered billing to track the users and notifications? What about the extra PoS system which is additional charge per month, that’s not metered and the customer should not be able to downgrade the plan unless my system allows them to(ex: bar has rooftop and regular bar, they would need 2 PoS systems and they can’t downgrade to 1 unless they delete one of the BarAreas from their account
rigid granite
No, you can't using Pricing Tables, https://docs.stripe.com/payments/checkout/pricing-table. You'd use https://docs.stripe.com/billing/subscriptions/usage-based instead and for cancelling/ or managing subscriptions you can use: https://docs.stripe.com/customer-management
You mentioned ' Also I need to handle the customer subscription changes upgrade/downgrade and cancellations on my own or will there still be a customer dashboard' earlier so I assumed you were using Customer Portal: https://docs.stripe.com/customer-management
If not, I recommend that you do as it makes it easier for your customer to manage these
crisp tinsel
But the customer portal won’t be able to verify if downgrades are allowed right?
rigid granite
That is correct: https://docs.stripe.com/customer-management#customer-portal-limitations for usage based billing
but they can still manage payment methods
crisp tinsel
Oh ok I see so that portal handles their payment method for subscriptions, and they would have to cancel their plan and then sign up again for a new plan if they wanted to switch from my $99 subscription to the $199 one since the plans use metered billing
rigid granite
Yes on the payment method management. On the upgrades, you can use use the API: https://docs.stripe.com/billing/subscriptions/change-price to manage that on your code
crisp tinsel
Ok so I can use pricing tables to kickstart the initial subscription where user can choose $99 or $199 and I would have to code all the addons and change subscription, and the customer portal will handle payments and cancellations?
rigid granite
I highly recommend that you try your entire flow end-to-end using you Sandbox account
You mentioned ' It doesn’t support usage-based pricing models.' earlier but the prices you're sharing is not usage based it does not look like.
If it's not usage based, you can keep using the Pricing Table
crisp tinsel
There’s a couple of different products, additional employee is an add on that will usually be fixed unless they hire new employees so I don’t think metering is right for that, I’d have another product like “extra employee” charged at $5 per month and that shouldn’t change when subscription renews.
Then I have push notifications which can work with metered billing or I can create another product “extra push notifications” but metering seems best for for that if I can allow the first 5 free
Then there’s the extra features such as PoS, inventory management, employee scheduling which are all monthly addons
rigid granite
In that case, why don't you use the pricing table to get them subscribed, and then update the subscription: https://docs.stripe.com/billing/subscriptions/change-price?
After the Pricing Table creates a Checkout, you chould be able to update the Checkout Session: https://docs.stripe.com/api/checkout/sessions/update?api-version=2025-05-28.basil
Can you try that?
It won't reflect the add-on items on the UI in the Pricing Table
However, if will show the correct/ upadted amount on the Checkout
crisp tinsel
Yea that’s what I was hoping to do, basically the pricing table creates the stripe account and subscription and then I manage all the options on my admin panel and based on inputs from there update the subscription, then the customer portal just allows to cancel subscription or change payment method, or will it allow change from $99 to $199 as well? My current implementation allows it to change plan and was hoping that changes are done on my end so i can verify that a user will be able to downgrade since the $99 has less features so they need to confirm they will lose access to all those things
Yea that should be fine, I plan on making like a subscription calculator on my dashboard so user knows what the charge is and then when they want to access the panel it’s ok if they see just the price
rigid granite
That makes sense.
I always recommend that you test this fully using the Sandbox account as well to vet that it exactly what you'd want
crisp tinsel
Yea I still haven’t gotten to prod. So many little things, but yea I have dev and qa then I’ll push to prod
rigid granite
Sounds like a plan!
crisp tinsel
One last thing, is the pricing id going to change when I update the subscription? I was hoping there would only be 2 price_xx ids which I can use to distinguish from $99 and $199. And would I just update the price itself or do I create stripe products for the employees and all that or no need if I can just calculate on my dashboard and pass the price
rigid granite
Yes, it would. For each price, you will have a different price id
crisp tinsel
I’m going to hold all the quantities and all that in my db so I can populate that to the user everytime, just not sure if stripe need products and quantities for the item
rigid granite
You'd pass the price id and the quantity
crisp tinsel
Oh so when I make an update to the subscription it will change the price Id? Because from pricing table I initially get only 2 ids but if changing the price updates it then I’ll have to save the base plan name in my db I guess
rigid granite
Yes, when you make the upgrade if't s a different price id, yes. Otherwiste, if you're just changing the quantity, then no
I think testing this will be helpful to better understand the flow entirely
crisp tinsel
Yea I agree I’m just trying to figure out the implementation, so since my notifications is metered usage the price is can vary all the time? Just want to make sure that priceID is not something I can rely on anymore to distinguish the plans