Dennis H. Lewis shows why Bubble's native Stripe plugin is too limited, then builds a better one using the third-party Stripe Payment Element 3DS plugin. The native version forces redirects, hides most Stripe features, and breaks workflows on failed payments. His custom element embeds payments directly, supports multiple methods, and handles failures cleanly.
Chapters
All right, so in this video, I'm going to show you exactly how I integrate my bubble applications with Stripe for getting the native plugin and native stripe functionality built into bubble. Let's face it, this is one of the most critical moments in your application's relationship with its users. How you handle your payments. Every little drop of friction that you add into the payment process needs to be considered, and it needs to be as polished and smooth as it possibly can be. You want to make it as easy as possible for your users to get over that hump and make the payment so that you can convert your bubble application into a real life business in the real world. Let's jump in first and just talk about why I don't recommend using the native stripe functionalities.
So, first of all, with the native stripe functionalities, you can't embed the stripe payment into your bubble page. It's always going to open it up, the take it to the Stripe page checkout page, and then it'll return back to bubble. For me, this is a little bit too clunky. Second thing is that you can't access all of the payment API functionalities from within the native bubble functionalities. Sometimes you need to do a little bit more and you run into a wall and you say, oh gosh, now what do I do? The third thing is that you can only handle one customer ID per user using the native strike functionality. This probably isn't all that important for many use cases, but when you do run into the necessity of wanting to be able to handle multiple stripe identities for one bubble user, be it because it's a marketplace functionality or because you have a seller's profile and a buyer's profile and they have to be able to use separate stripe identities, it's just not going to be possible with the native stripe functionality in bubble. And primarily, another thing that you need to understand is that when you use the native functionality, if your payment fails or if they bail out halfway through and they don't complete, this will just break your bubble workflow. It doesn't recover gracefully, it just stops that workflow. So everything that was going to happen afterwards doesn't happen. Which probably is okay because you probably don't want it to because it's failed, but you lose control there. All you're going to see is that it didn't happen, and you may not even know from within your application that it didn't happen. For me, these are reasons why I prefer to build my stripe integrations another way. What I'm going to show you now is exactly what I do and how it fits into my bubble applications and hopefully that will help you in building yours. So here we are. This is one of our ratio.dev sales pages for Serpi, which by the way is amazing. Probably do another video on the actual functionalities of this checkout process because I think it's pretty slick and pretty cool. It's got some built in scarcity built in and it has some additional kind of things that it can do. But basically they're going to click on a button here, they're going to, in this case they're going to see the bonuses and when they click to subscribe, it is going to open this up inside my pop up. So here you're seeing it is completely seamless for the user. It supports the different payment methods that you've set up in your Stripe backend. So in this case Cash App or Apple Pay or whatever it is that it detects that you've permitted. So if you want to put PayPal into your stripe account, you can do that as well and take payments via PayPal. And then you just put in your information, you click a button and you're good to go. And it is a perfectly well integrated process into your user experience. There's no going off of your application, there's no going anywhere else. And I think that is a major benefit. So now let's go and jump into the bubble builder and let's see exactly how this is all set up. Kind of open this up here and I'm on this page, this is my page. But in this case what we do is we use a reusable element that we've already built so that we can quickly add in a new product or whatever and put it in. But before we get there, I'm going to show you the plugin that I recommend that you use for your stripe integrations. So we're going to come down here and it's called stripe payment element 3ds. And here it is, you can see what you've got going on there. That's all you have to do is plug in your API keys and then set it up in your workflow. So as far as loading the plugin and getting it configured, that's really simple. And now what we're going to do is I'm going to take you into the reusable element that we've built and show you how it's all set up. So I'm going to come in here and this one called Stripe Payment.
And so what you can See here is, this is a. I've set this up as a group so I can put this on a page, I can put it in a pop up, I can put it wherever I want. And I have parameters that I pass into it so that I can set what is the subscription plan that it's going to be using, what is the amount that I'm going to be charging, Do I allow refunds or do I not allow refunds? It's all modular here. But the most important thing is that in this step.
We have an element which is called stripe embed. And so here we're going to just use the.
Fill out this information. The return URL, I just send it back to the same one. I can set the colors so that it matches my colors in the payment process. I can set the text colors so I can provide the initial information. If I have it for my user, I could put that in so that it automatically goes in. This allows me to embed into my group the process. But that isn't quite enough. We also have to look at the workflows that go on here because it is a little bit more complicated than the native strike functionalities. So I'm going to go into the workflows tab and I'm just going to show you. So I have a workflow here called Launch.
So what I do is from my page and I triggered this workflow in the reusable element so that it will set everything up and get it all correctly put together. If the user has a stripe ID already associated, I don't do this, but if they don't, I'll create stripe user for them. Then you're going to use this to create the payment intent. So here's where you're going to pass it. You know it's going to take the amount and it's going to. You're going to pass it the currency, you're going to give it the customer id. You're going to say if you want it to set up for future payments or not, or if it's just a one off, then you're going to initialize it, which is just going to take that payment intent and initialize it. I do some logging on my part here. I set a couple of custom states and if it's a new customer, then I'll store their ID there and that means that it will get the process set up and that makes sure that all the data is in there for the group. The embedded payment group will populate its data correctly and show up on the screen. Correctly, then there's two other things that I have set up. One is if the payment succeeds, and one if the payment fails. This is interesting because now I have control. So if it succeeds, what I can do is schedule some backend workflows based on my application functionality and the parameters I've set up. It will do one thing or it'll do another. And if it fails, it will set custom state so that it will say, hey, your payment failed, you want to retry. I could store that in a database of abandoned carts or errors. I could send myself an email saying, hey, this customer payment didn't go through. You want to reach out to them. You can make that as graceful and as useful for your business case as you want. So it gives you a lot of control over what's going on. For recurring subscriptions, it's a little bit different. If it's a subscription, you're going to actually have to make a few little changes here. You're going to use a different action, which is set up a subscription instead of just a simple payment intent, and then you'll set up the payment intent. The process is just there's another step in there, but it's still pretty much all the same, and you still can have it in your reusable element and make this as seamless for your users as you like. This allows you to store. Since you're storing the customer id, you can store it in any table that you want. So that eliminates the problem of not being able to have more than one for a user. You could have it and store it in a separate table. You can handle that for security reasons. If you want it to be completely separate from your user table, you can do that as well. See if the transaction succeeded or failed. This is basically, in a nutshell, the entire process of how we integrate Stripe with our bubble applications. I hope you've enjoyed it. If you need further assistance, if you want us to step in and just make your payment process as smooth and as solid as can be, feel free to reach out to us here at ratio.dev, we'll be happy to lend you a hand and I hope to see you on my next video.
