Stripe webhook setup - Step-by-step

[adamhholmes]

@darren.james7518

I thought Stripe saved that info automatically and the Request Data's object customer function would pull that in via the webhook.

Stripe saves that data in their own database, then include it in the webhook payload. The Request Data’s Object Customer will be the Customer ID, but if you want to store it in your own app’s database then you need to actually do that in your workflow (it won’t just happen - how could it?)

although I sense something is not right.

Well you’re right about that… in your screenshot you’re just setting the value to itself (again) which literally does nothing . You can’t set a value to itself and expect it to change - it’s the same value (which presumably is empty to begin with, so it will remain empty).

As you can tell, I have no clue how to save the Customer ID, reading the Stripe Documentation isn’t helping as there’s no reference to Customer ID, only Customer tax IDs.

You can only get the customer ID from Stripe either via a Webhook or API call (I don’t think you can get it via the Bubble Stripe plugin)…

So to save it on the User datatype (or any other datatype) you need to identify the User (or other Thing) in question…

Obviously you can’t identify that User by the Customer ID (as you don’t know it)… so you’ll need to find the User by some other means (presumably the only data you have to go on is the email address, so use that). Then you can save the Stripe Customer ID wherever you want to save it.

[darren.james7518]

@adamhholmes

Stripe saves that data in their own database, then include it in the webhook payload. The Request Data’s Object Customer will be the Customer ID, but if you want to store it in your own app’s database then you need to actually do that in your workflow

Thank you again. I agree that in my screenshot I’m just setting the value to itself, which I agree makes no sense but the tutorial kind of did this! Although he was saving Stripe fields to the User Datatype. Here’s a screenshot of his tutorial;

In any case, I don’t want to set the value to itself, I agree that is pointless and I have updated the CustomerID reference to be the Current user's email (see below).

I’m unable to test anything due to the before mentioned error message which logs me out, even when I click “run as” from my App data I am immediately logged out.

You can only get the customer ID from Stripe either via a Webhook or API call (I don’t think you can get it via the Bubble Stripe plugin)…

Thanks, at least I know that ultimately I need to get customer ID from the Webhook and to identify the User I need to save the user’s email to my database. I still don’t quite see the bigger picture on how to do this but every tiny step forward gives more context.

[darren.james7518]

I’ve fixed the error preventing me from logging in so I was able to test using the Current user's email as CustomerID, I created a new user and checked out but as before no info is saved to the database. Since I have given the Status a default value which should also populate the databse (which it’s not) I am lead to believe the ‘Thing to change’ is not working … silly question but is this why all the tutorials say to store Stripe’s fields within the User datatype? I store in Subscriptions purely as it’s tidier.

[adamhholmes]

I created a new user and checked out but as before no info is saved to the database.

No of course it’s not… you’re not identifying the User in the backend workflow so nothing will work…

I am lead to believe the ‘Thing to change’ is not working

Yes, that’s exactly what’s happening, as you’re not defining the Thing to change correctly…

Currently you’re searching for a User, based on matching that User’s Stripe Customer ID (which by the way is a field you’ve deleted, so it’s no longer there anyway), to the request data’s Customer, then selecting that User’s Subscription.

So there is no User being defined (as none of your User’s have Customer Ids as you’re not setting them, plus you’ve deleted the field from your app anyway), and therefore there is no Subscription being defined - hence nothing is being updated.

silly question but is this why all the tutorials say to store Stripe’s fields within the User datatype? I store in Subscriptions purely as it’s tidier.

You can save your data anywhere you like, but it’s much more logical to save the Stripe Customer ID on the User datatype not a Subscription (as it relates to a Customer, not a Subscription), and the Subscription Id on the Subscription datatype (as that’s what it relates to).

For instance (perhaps not in your app, but in others), a User may have more than one subscription, or they may cancel one then create another - so storing the Customer ID on the subscription is confusing, and unnecessary (as you would surely be storing the User on the Subscription so can access the Customer ID via that if needed).

Anyway to solve your problem you just need to define the Subscription that you want to change correctly…

There are a few ways to do that, but surely the simplest is just to do a search for the subscription who’s subscription Id in your database matches the Subscription ID in the request data (assuming you’re storing the Subscription ID correctly in your database, which it looks like you are).

If you want to make changes to the User, the easiest way will be to reference that subscription’s User. (alternatively you can make an API call to retrieve the Customer, and then use the Customer’s Email address to match the User from your own database).

[darren.james7518]

Thank you so much for the info, I see what you mean, well I need to read through a few times as I’m grasping as I go but I definitely hear you. I’m going to also do what you suggested and save the Stripe Customer ID on the User datatype. I will have a deep dig into this again and refer back to your info above.

[adamhholmes]

All you need to do is this…

To make changes to the Subscription, set the Thing to change to be Search for Subscriptions: Subscription ID = Request Data's Object ID: First item

To make changes to the User use: Search for Subscriptions: Subscription ID = Request Data's Object ID: First item's User

Note: although looking at your app again, I can’t see where you’re creating the Subscription in your database in the first place, nor assigning it to the User, so you’ll need to make sure you’re doing both of those things before you can make any changes to the subscription (obviously).

[darren.james7518]

That’s super helpful, thank you.

Out of interest, if you have a minute can you see how this user is able to refer the value to itself, he does this at 5:14sec in this video

He is doing the following:

I ask because it doesn’t work for me, even when I copy step-by-step. I am not going to refer the value to itself, but I was curious that’s all!

On a separate note, it seems to me, even before I worry about the webhooks, the following workflow should at least be saving the User’s email to the database field because ‘StripeCustomerID’ is in the User Data type now. If this isn’t working then maybe you’re right, I actually don’t know how to save data!

[adamhholmes]

@darren.james7518

Out of interest, if you have a minute can you see how this user is able to refer the value to itself, he does this at 5:14sec in this video

He’s not… (you’re misinterpreting what you’re seeing) those are 2 different things…

He’s setting the database feild Customer_Stripe_ID to a value which looks to be coming from the Stripe plugin…

I honestly can’t comment much on any Stripe plugins, as I’ve never really used any… but having just had a quick look at the Bubble built one it does appear that it saves the customer ID on the User datatype, so you should just be able to reference that to get the customer ID as he is in the video (so no need to set it on the backend after all)…

On a separate note, it seems to me, even before I worry about the webhooks, the following workflow should at least be saving the User’s email to the database field because ‘StripeCustomerID’ is in the User Data type now. If this isn’t working then maybe you’re right, I actually don’t know how to save data!

Yes, it should (but why would you want to save an email address as the Customer ID)?..

In any case, as I said above, it turns out you can get the customer ID directly from the plugin (as per the video), so that’s definitely the simplest way to do it.

[darren.james7518]

@adamhholmes

He’s setting the database feild Customer_Stripe_ID to a value which looks to be coming from the Stripe plugin…

Thank you for looking into that video Adam. This is where I must have been mixing things up before. I will get the customer ID directly from the plugin from now on.

Yes, it should (but why would you want to save an email address as the Customer ID)?..

No reason, just as a quick test as I wanted to see if anything would save to the database!

[adamhholmes]

@darren.james7518

This is where II must have been mixing things up before. I will reference that one to get the customer ID.

Yeah, I can see how that could be confusing…

[darren.james7518]

Perhaps using the Stripe plugin is the reason I haven’t been able to save data to the ‘Subscription’ Datatype.

If I add all the Stripe fields to the User datatype then all data saves as expected. But if I try and save anything to the ‘Subscription’ Datatype I am unable to. You had said that you can’t see where I’m creating the Subscription in the database in the first place, nor assigning it to the User. I’ll admit, I can’t figure out how to assign the User to the Subscription and I think this is why no data is saving to the ‘Subscription’ Datatype.

To illustrate, making changes to the User does work …

But this doesn’t work…

You had also mentioned that to make changes to the User use: Search for Subscriptions: Subscription ID = Request Data's Object ID: First item's User but I think this refers to the backend API workflow.

[adamhholmes]

@darren.james7518

But this doesn’t work…

Yeah, having looked again at your app again, it doesn’t look like you’re creating a Subscription in the first place and assigning it to the User (and vice versa) so there’s nothing to change (there certainly aren’t any Subscriptions in your database)…

You had also mentioned that to make changes to the User use: Search for Subscriptions: Subscription ID = Request Data's Object ID: First item's User but I think this refers to the backend API workflow.

Yes, that’s if you’re doing it on the backend via a webhook (which you were originally).

[darren.james7518]

@adamhholmes

Yes, that’s if you’re doing it on the backend via a webhook (which you were originally).

Yes this will be useful when I set up the backend webhook.

[darren.james7518]

@adamhholmes

Yeah, having looked again at your app again, it doesn’t look like you’re creating a Subscription in the first place and assigning it to the User (and vice versa) so there’s nothing to change (there certainly aren’t any Subscriptions in your database)…

I still can’t save data to the Subscription Datatype so I’ve posted a question on this specific issue as it may be a limitation with the Stripe Plugin.

[adamhholmes]

Where are you creating the subscription?

[darren.james7518]

@adamhholmes

So the best way to do it (this is how we do it in our Subscription apps)… is to set up a Webhook in Stripe with the customer.subscription.updated event and point it to your endpoint (API Workflow) in Bubble.

Then, in that API workflow, use a conditional action to trigger another workflow, based on the request data’s object (specifically: when request data's object cancel_at_period_end is 'yes' AND request data's object status is 'active' (you’ll probably also want to compare it to something in your own database to prevent the same workflow from running again if the user makes some additional change to their subscription, such as comparing your own database’s subscription status, or cancel fields)

Then use the second workflow to make the necessary changes to your User in your database.

How do I use a conditional action to trigger another workflow? I want the Thing to change to be a workflow, but obviously a workflow isn’t a Thing so I’m stuck!

I think this task of updating our users immediately when they click ‘unsubscribe’ is so important and I am amazed that Stripe fails to provide an Event for this in their subscription webhook events.

[adamhholmes]

How do I use a conditional action to trigger another workflow?

Just add an action to schedule the workflow, and put your conditions in the ‘only when’ box.

I want the Thing to change to be a workflow, but obviously a workflow isn’t a Thing so I’m stuck!

I don’t know what that means? (how can you change a workflow?)

I think this task of updating our users immediately when they click ‘unsubscribe’ is so important and I am amazed that Stripe fails to provide an Event for this in their subscription webhook events.

Well they do… The customer.subscription.updated event (they can’t have an individual event for every possible action, there would be thousands) - they have an event for Subscription Updated, and all the information you need to know exactly what that update is is contained in the event object data. That’s why you need to use conditional actions in your workflows to run the correct workflow depending on the type of update to the subscription.

[darren.james7518]

@adamhholmes

Just add an action to schedule the workflow, and put your conditions in the ‘only when’ box.

Ok thank you, I will try this.

Well they do… The customer.subscription.updated event (they can’t have an individual event for every possible action, there would be thousands)

True, Stripe can’t have an individual event for every possible action, but when it comes to subscriptions I feel there would be three most basic ones;

1. Subscribes to a recurring plan
2. Cancels/deletes a recurring plan
3. Last payment has been made (subscription ended)

Stripe neglects to offer a webhook for ‘cancels/deletes’.

Even worse, the webhook called “customer.subscription.deleted” is NOT for when a user ‘deletes’ a recurring plan but is instead for when their subscription ends. It would have been more logical to name it “customer.subscription.ended”.

It’s important to offer a webhook for when a user ‘cancels/deletes’ so we can notify our users immediately with something like;

“You have just cancelled your plan and your last payment will be on [date]”.

I might suggest this to Stripe and suggest logical naming such as;

Subscribes to a recurring plan [customer.subscription.created]
Cancels/deletes a recurring plan [customer.subscription.deleted]
Last payment has been made (customer.subscription.ended)

Anyway, little rant over!

I’ve added an action to schedule the next workflow, and want to update my database so I know the instant a user clicks ‘unsubscribe’. But, the following must be wrong as no data is saved.

[adamhholmes]

@darren.james7518

I’ve added an action to schedule the next workflow, and want to update my database so I know the instant a user clicks ‘unsubscribe’. But, the following must be wrong as no data is saved.

You can’t refer to the Current User when using webhooks (there isn’t a current User being passed from Stripe, obviously), so you have to define the User manually, and then pass that user into all subsequent workflows (there will be no current user in any subsequent workflow).

Although, as you’re making changes to a Subscription, not a User), you can just define the subscription.

[darren.james7518]

I had this set up previously but that didn’t work. Isn’t this defining the subscription correctly? Ugh, I definitely need more experience with making changes to the Database, it’s my weak spot.