The workflow executes successfully with the user being created, the team being created, etc. The logs both on Bubble and in Stripe also notate that everything ran successfully, so there are no apparent hiccups there.
For some reason, the user is not logged into the app after this. This is necessary because after the user purchases a subscription to my app using the Stripe Pricing Tables embed, I want them to be logged in and redirected to their dashboard within the app.
I’m not sure I follow, but from what I understand you cannot add navigation workflows in backend workflows. They do not show up. The only one that does is “terminate this workflow”.
I wasnt able to successfully implement this workaround. Most likely because I am missing some steps or did not understand it correctly.
However I believe I identified a part of the issue. It seems that even though I can run the workflows as the current user, and create things that are eventually attributed t the current user, when doing it through these backend workflows, Bubble does not recognize me as the current user.
So I can perform a sign up, but its as if I’m signing up for a user that is NOT me. So it executes, but its not attributed to me.
I’ll have to take a few more tries at implementing your suggestion, but I think I’m missing a few steps or I’m a bit confused on the specifics.
Maybe you should do this instead. Have them checkout, once the webhook fires you then should “Create an account for someone else”, shoot them an introduction/welcome email letting them know and provide them with the url to navigate back to to sign in with provided credentials. Upon signing in, prompt them to change their password.
You might want to check out this post where I accomplish something similar. The big issue I can see with your current flow is that you can’t trigger to log the user in from the server. You can create the account, but to log them in, that needs to initiate on a page workflow
Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand
Yes, that is exactly my problem. I know it can be done, I just need to be pointed in a few directions. Doug was providing me with some good pointers, and I’ll be checking out your video as well.
Firstly, thanks for your video. I’ve watched it several times already and gained some valuable insight that what I want to do is possible. I continue to need a little help and I was wondering if I could pick your brain.
Unfortunately, there are a few key differences in our implementation that makes it more challenging to replicate your steps.
One major difference is that my checkout method is done through an embedded Stripe Pricing Table. This is important because it means there is no first step where I add a button to create the checkout session, because its already built into the embed. This also means that I cannot have a step where I create a Magic Link and use it as the Checkout Session’s success URL.
Because of this, I’m not able to implement your exact solution. But I’ve gotten close to something similar.
I tried to implement a magic link in my current backend workflows, but I’ve discovered that magic links sent as part of a backend workflow fail, error out, or are flagged as unsafe links depending on the web browser, or possibly email provider.
So I guess my question is, have you encountered this issue with magic links in backend workflows and how have you worked around it?
If I’m able to get this piece working, I can use a magic link to log the user in after the checkout.session.complete webhook kicks off and then have them change their password.
Unless there is a strong reason to use Stripe’s pricing table, it might be easier to build the pricing table into the page natively in Bubble to give you more flexibility. It could very well be one of these situations where you go with what seems like the most efficient route, but end up spending more time building workaround solutions that are less secure.
Unfortunately (as far as I’m aware) you’re not able to set a dynamic success URL with a pricing table - it’s static. In my example I set the success URL to the magic link so the user is automatically logged in once they are routed back.
You keep mentioning trying to generate magic links in the backend and logging users in, but this just isn’t possible (see my earlier message - this needs to occur in the front end). The only thing you’re able to do with a magic link generated in the backend is email it out to the user. I wouldn’t think it’s a desirable user flow to send the user back to Bubble after they’ve completed checkout, only to have to go to their email to click a magic link.
The only possible route I see is this.
Generate a new user with a temporary user account when the page loads (if a user isn’t already logged in) where the Stripe pricing table is situated. Also ensure the user is logged in at this point.
The Stripe pricing tables allow you to send across a user identifier - i.e. you could send the unique ID of the user you’ve just created. To do this you need to add an extra bit of code to the code snippet Stripe give you. See the bolded section below - this was the additional code and you can set the xxx to be the unique ID of the user record you’ve just created.
You’ll be able to reference that unique ID in your webhook to update the payment details in Bubble.
When your user is routed back to Bubble they should still be logged in. It’s not as foolproof as using a magic link but they should be logged in.
Have some sort of cleanup process running on a schedule (say hourly, daily) that will delete any of the user accounts that never get converted. i.e. people abandon the page / don’t complete payment.
Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand
Yes, I’ve been leaning towards the same conclusion.
Fortunately I’ve already built this into the app but I wanted to try this embed because I thought it would be cleaner and more efficient.
Well, on the flip side, the workflow I had already built in Bubble did most of the things but was missing the logging user in part that your video covers, so I’ll be working to add that final piece.
And you’re right. The success URL for the pricing table is static and you can set a confirmation page for each product in Stripe.
Can I ask what do you use to initialize the Create a Checkout Session call?
I keep trying to use URLS from within my app for the success URL and it just wont initialize. I keep getting a “parameter missing success url” response.
In the example I provided above, I set the success URL to the magic link. On other apps I’ve often just routed people back to where they were before (i.e. just use This URL).
Not sure why this is happening in your case, but it’s probably got to do with the formatting of the URL… check that it’s a full URL… i.e. https://
Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand
You guys have been an amazing help. I was able to successfully modify the checkout workflow I had built in Bubble prior to my attempt at implementing the pricing table and it all works as intended, including having the user update their password and login.
Shame that I couldnt get the Pricing Table to work. But its motivated me to make it a side project and figure it out. I also read somewhere that Stripe will be working on a way to allow their checkout sessions to create user login workflows sometime in the future, so I guess we’ll see.
Thanks to all for going through this scenario. Can I ask if you’ve tried further to get the pricing tables working? I have a need to allow users to purchase on a per-seat basis (ideally before they sign-up and create an account), so the volume-based products in stripe are perfect. but i’ve also run into this issue of needing to re-direct the users to their dashboard after the purchase is complete, and to have them logged in straight away, which is currently not happening and is a sticking point for me.