I am using the API connector to set up a Stripe call that lets users switch their current subscription plan. The reason I am doing this is because, in the event that a user upgrades or downgrades their plan, I would like to immediately charge them a prorated amount (or provide a credit) for the remainder of their billing period. From what I understand, Bubble’s Stripe plugin does not allow this behavior and will instead charge at the end of the billing cycle.
However, when setting up my API call as follows, rather than switching the user’s subscription to the new price, it simply adds the new price to the subscription, so that the upcoming invoice will have charges for both the new and the old price
My question is, is there something wrong in my setup below that is causing this? Additionally, are there better ways of handling this scenario where the user switches their plan (perhaps the default way Bubble provides is better from a business standpoint for some reason I am missing, though I would have assumed most SaaS companies charge a prorated amount immediately. I’d love to get peoples’ thoughts on this matter).
Stripe’s native portals/sessions are the way to go.
Then implement webhooks when a subscription changes or invoice is paid.
Thank you for that info!
Why is using Stripe checkout and webhooks preferable to using the API connector? Theoretically, the API should be able to handle this, but there is probably something wrong in how I set up my call that is causing the issue.
With that being said, if this method is more robust, I would be interested in exploring it. I am still a little confused about how I would implement the webhooks to trigger events in bubble. Does this essentially involve exposing the API endpoints for my app and getting stripe to make calls to my app that trigger workflows?
- Stripe handles all of the math
- No need to build UI for payments
- No need to build UI for billing
You set up webhooks in Stripe. That part is simple. You need to build backend workflows in Bubble to handle the incoming data. I’m sure there’s a bunch of info on the forum about specific implementation.
Great, thanks! I am looking into this. Still working through how to set up the checkout page to allow switching between the different plans I offer, but it seems like this could be the way to go.
Here’s how customers update their plan through their Customer Portal. This is different than Checkout.
So if I understand correctly the general workflow after setting up the customer portal in the stripe dashboard is:
- A customer clicks the action on the bubble site
- a POST request is sent along with the CustomerID to create a portal session
- redirect the user to the Stripe redirect URL returned as part of the response from the POST request
- user makes the changes in the customer portal
- User is redirected back to bubble
- Stripe’s webhooks notify bubble of the changes, which kicks off the workflows to update the user’s permissions, etc. in accordance with the new plan
Thanks for the help. I agree, this seems more robust than what I was originally trying to implement.