Using Bubble’s normal stripe plugin for a site, I want to sign up a user on a subscription to a product I have created in Stripe. I duplicated the product in Stripe from test to live, and this creates a duplicate price.
This however is in Bubble’s manual:
‘Since the app has two versions, Development and Live, you need to have both versions of your account in Stripe to have the same plans with the same IDs.’
Problem is, Stripe do not allow to prices/plans to have the same IDs. Am I being stupid here or is Bubble’s plugin out of date? You can only select the test version of the plan in the workflow, you cannot select the live or enter the plan dynamically or by typing.
Yeah. You are correct. It used to work, it doesn’t work that way anymore. You have to use dynamic data and then choose “Isn’t live version” formatted as text. Then for ‘yes’ put your test id and for ‘no’ put your live id.
Basically, as far as I know, Stripe always had a clear separation between LIVE data and TEST data within Stripe…which would mean you were never able to have the same IDs for your LIVE and TEST data, since Stripe requires you to create things, such as products, prices etc. in each version separately, and for the most part, people will just allow Stripe to generate those IDs…which means, if you created a Product in your TEST data, that product does not exist in your LIVE data, and if you wanted to create the same ID within Stripe for the Product you would need to generate that ID yourself, which I don’t think any Stripe plugin allows you to do, although you can when connecting to Stripe directly through the API.
Additionally, Bubble Development database and LIVE database are completely separate from each other, so easiest thing to do is to understand that, and just create in your Bubble LIVE database the necessary data entries to populate the values needed that correspond to the LIVE Stripe data.
In my apps, I create CRUD components to create all products, prices etc…so once I go LIVE, I just simply use the CRUD component to create all the Stripe data I need in LIVE.
@boston85719 a little history on Bubble… Back in 2016 when I first started using Bubble, they would pull in the test and live subscription data automatically for us. Made it super easy to set up. It felt magical how easy it was because of them doing that. That changed at some point when they did an update and going forward that part is just broken. Choosing a subscription plan statically the way it was originally designed doesn’t work anymore. Now we have to choose ‘dynamic’ now. Hope that makes sense.
Or, I guess maybe Stripe might have had the same IDs available in test and live and no longer offer that. I’m not sure. Maybe they are the ones that broke it.
I imagine that as more likely since there would not have been a way for Bubble to know which is the LIVE versus the TEST data from Stripe itself to magically make the connection based on the development versus live version of the Bubble app.
Well, it used to display the plan name, not the ID. So I think they used to look for matching names and did the work for us. I think by 2018 this changed. It was convenient but obviously could create issues. They should just remove the static option and have one that says test plan ID and one that says live ID or something.
I bet what it was then was that the plugin had a create subscription function which ran two API calls to Stripe, one to create the plan in the LIVE data and one to create in the TEST data…likely what the Bubble plugin did was used the name of the plan as the ID in the API calls (we can either allow Stripe to create the ID or add our own), so that both the TEST and LIVE subscription IDs were the same in Stripe.
In any situation, now I personally think best practice is to re-create the subscriptions and other Stripe Objects in the LIVE Bubble app, so that those values are stored in the Live database, but the suggestion of using ‘isn’t live version’ formatted as text could work as well.
I think there’s a better solution for most apps than this or using option sets.
In my base app template, I have a couple of webhooks that mean subscriptions/products are all managed entirely in Stripe, rather than Bubble, as it’s easier than adding that in an admin panel. All you need is a product updated webhook, and a price updated webhook.
Product updated
Create a plan/product if it doesn’t already exist in the database.
You can use Stripe metadata to specify things like credit limits, whether the plan is active etc. So, if I add a metadata ‘creditLimit’ to the Stripe product and then change it, the change in credit limit will automatically be reflected in my app. Similarly, pricing tables search for all visible plans so that to archive a plan the client just needs to change active to no. ‘Highlighted’ can also be set which dictates whether it gets highlighted in pricing tables. Images, feature lists etc all automatically update too. If your app limits feature by plans, you may have a list of features as metadata so you can just do ‘Current user’s Plan contains (this feature)’.
Price updated
Similar kind of logic here, create a price if it doesn’t exist and then add it to the relevant plan/product. Stores the currency, the billing interval, the amount, and whether it’s active (purchaseable).
All updates on Stripe are auto-pushed to the correct version of the Bubble app with no additional config necessary. It just works, always, and doesn’t require pushing anything to live.
So instead of re-creating the wheel and making your own CRUD element, you leverage the Stripe dashboard to create all the products and prices, and rely on having webhooks to create the entries in your Bubble database…nice.
When doing this, do you have to create the product from the Stripe dashboard in both LIVE and TEST environments?
Of course, but that’s not a problem. I might create ‘Test Basic’ in the test mode and it’ll be pushed to development mode, and create ‘Basic’ in the live mode so it’ll be pushed to live mode. The workflows in the app for permissions rely on metadata of the product rather than the product ID itself (like it might with option sets for example) to work out how to treat a user. Hope that answers your question
It does. Didn’t think it was a problem to need to do it in both LIVE and TEST…was just curious if there was a clever way to do it without that you might have also come up with.
Definitely an approach I’ll be able to consul clients on implementing as I do for some other functions that I explain does not need to be recreated in their Bubble app and they should just leverage the Stripe dashboard.
For any other apps that require users to create their own subscriptions and products, will still need to use the other approaches though. But this is a very clever implementation for apps that are the only seller.
Yeah, it’s great for SaaS. The only ‘watch out’ is to make sure that clients understand the metadata they must add (or must not edit) on products. So, they need to understand for example that the credit limit metadata key must be creditLimit not CreditLimit for example. But it saves a lot of development time and is quite robust which generally clients opt for.
