Stripe webhook setup - Step-by-step

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!

1 Like

Yeah, I can see how that could be confusing…

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.

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).

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

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.

Where are you creating the subscription?

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.

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.

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.

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.

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.

Yeah, as I said there is no current user in a workflow triggered via a webhook, so that won’t work.

So to be clear, I have everything correct apart from the Customer ID? If that is so, then I understand I can’t refer to the User directly, I can’t do a Search for and I can’t use the Request data … I don’t see how I can tell Bubble that the Thing to change relates to the User.

The options available are;

I don’t see how I can tell Bubble that the Thing to change relates to the User.

Well, firstly, it doesn’t relate to the User (you’re changing a Subscription, no? not a User)… so there’s no need to refer to the User at all here, just refer to the Subscription directly (based on the webhook data)…

But if you want or need to refer to the User as well then there are several ways to do it.

The simplest way is just to to refer to the Subscription’s User

Another way is to use the request data’s Customer (which is the Stripe Customer ID) to find the User.

Alternatively, you could make a Retrieve A Customer API call (with the Customer ID from the request data) to get the customer’s email address and search for that.

There are probably other ways too…

By the way, I’m talking here about in your API Endpoint workflow… in subsequent workflows you just need to pass the relevant data into the Workflow as a parameter.

Thank you for the additional information.

But if you want or need to refer to the User as well then there are several ways to do it.

No, I just need Bubble to know that the updated subscription relats to the current user.

refer to the Subscription directly (based on the webhook data)

Do you mean like this?

There’s no such thing as the current User in a workflow triggered by a webhook…

I assume what you mean is you want Bubble to know that the subscription relates to a particular User (but you must define that user somehow).

In any case, it’s the Subscription you’re working on here, so assuming your database is set up to store the User on the Subscription then that’s all you need to define the User (if you even need to do that at all)

Do you mean like this?

Yes, but obviously you don’t just want to change the first subscription in your database (unless that is what you want to do)…

Presumably want to change the subscription in your database that relates to the Subscription in the Stripe webhook?

So add a constraint to match the Subscription Id in your database (which you set when creating the subscription) to the subscription ID of the webhook object (i.e. the request data’s object ID)

Yes that’s correct.

Presumably want to change the subscription in your database that relates to the Subscription in the Stripe webhook?

Yes

So add a constraint to match the Subscription Id in your database (which you set when creating the subscription) to the subscription ID of the webhook object (i.e. the request data’s object ID)

The request data’s object ID is not available.

I’m guessing you’re in the wrong workflow then, you can only access the request data in the API Endpoint workflow which is what you need to be in.

Then pass the data on to subsequent workflows in the workflow parameters.

I don’t think I am in the wrong workflow. The backend workflow first receives the customer.subscription.updated payload. This happens when a user click unsubscribe in Stripe.

Then, When the user is still active AND is set to cancel at the end of their billing cycle, I go to the next API workflow to update the my database’s field “Plan.Cancelled = Yes” - I should be able to then use that data to display Text saying "Your plan has been cancelled and will expires on [date].