I need some help, because at this point I think that Bubble has a bug.
I’ve got a very straightforward setup where I send a subscription to stripe and its webhook comes to bubble and populates both the USER and SUBSCRIPTION datasets. At least it’s supposed to. When I review the raw data of a webhook, I can see that the stripe object_client_reference_ID is, in fact, matching the user’s unique ID (which is part of the setup), but when the webhook is received, it’s not writing to the USER dataset at all and it’s only partially writing to the SUBSCRIPTION dataset.
So I went into debug mode. I added two fields on the SUBSCRIPTION dataset:
debug_on_user_ID - uses a USER search constrained by unique ID = request data’s object’s client reference ID
debug_reference_ID - simply uses the current user’s unique ID
No matter what I do, every time I run through a test checkout, these 2 numbers don’t match. Instead - and this is what’s perplexing - bubble returns a DIFFERENT USER entirely on the searched field.
I’ll note, just to be thorough, that when I send a person to stripe to pay for a subscription, they’ve already been assigned a bubble user ID and in the data sent to stripe it sends “&client_reference_id=Current User’s unique id”. Stripe should not be receiving another person’s ID.
Can anyone explain to me what’s happening? Is it possible this is a bubble bug when using the stripe API plugin?
ok, so I solved one thing. Bubble isn’t finding the wrong user; it’s not finding ANY user. (I forgot the constraints on the search field in my debug, so it was just pulling the first client out of the database).
So here’s what’s really happening. I send a request to purchase a subscription. In the body field that gets sent to Stripe it includes the “current user’s unique ID” as the stripe “client_refererence_ID”. After purchase, and when the webhook comes through, it appears like the proper ID comes through too (my debug_ref that uses “request data’s object’s client ref ID” is showing the correct and current user), but bubble is still not finding a user.
I’ve been trying to constrain the USER search to “unique ID = request data’s object’s client reference ID”, but that didn’t work. So I created a temp field on USER called “stripe_checkout_ref”, which, when you select your subscription plan, writes to this field the current user ID. This also hasn’t worked.
I’m going to attach a screenshot, maybe that can help.
I gave up on the plugin because I’ve read there are a lot of bugs with it. With respect to redirecting, I have 2 buttons for 2 different subscriptions and the data are sent to stripe that way (including the success page url, price, and trial information). It works smoothly and the checkout process works fine as well (it clears in stripe). The problem is my backend workflow, I think, which is selectively choosing what to write into the subscription dataset and it outright refuses to write to the user dataset.
I tried a workaround, where the webhook (it’s a checkout session) only feeds data into the subscription and then I use 2 APIs on the success page to call up the session and subscription information to complete the remaining information and user data. That aint working either and I’m out of ideas.
Should this not be way more simple? What am I doing wrong here?
It is very simple if you use the Bubble Stripe Plugin, otherwise you have to build it all out on your own and also update web hooks so you make sure their subscription isn’t expired or something too.
I still need to build the webhooks in stripe, right? Does the plugin automatically listen to webhooks and update my datasets accordingly? I don’t really understand how this works. I’ll have to read more on the plugin.
If you use the Bubble Stripe Plugin, no, you don’t need to build out the web hooks. Bubble handles all of that for you. It will automatically update the Bubble built-in fields on the user as well.
Thanks for that. But the reason I gave up on the plugin is because I can’t find any actions except for checkout session and subscribe a new user. Other than that i see nothing else.
Apparently the plugin does not work well for updating subscriptions or canceling them, so it’s only good for signing up. You have to do API calls for the rest, which I think is ridiculous. I’ve tried many times now to update/cancel with the plugin and there’s nothing but errors.
Updating a subscription: apparently this function doesn’t work when you have a “flexible” subscription in Stripe, which is now Stripe’s standard. You can still sign up on “classic” but updates have to be flexible, which means the plugin is useless
Canceling a subscription: requires pulling the subscription schedule ID, which is something the plugin also doesn’t do. And the weird part is that not all subscriptions have this schedule ID (I have no clue why Stripe would do that).
What is your redirect uri that you are putting in Stripe?