Send paramaters to Stripe when creating a Payment Intent

I’m trying to create a Back End Workflow that when a Stripe Payment is successful. Part of its operation is to record the Order and associated Line Items in my app’s data. My problem is that a lot of the information for the Order comes from Custom States and as there’s no “Element Actions” option on the Back End workflow so I can’t record the Order.

I’m told that Stripe allows you to send a parameter when you create the payment intent and I understand this to mean that I can pass the details I need from the Custom States to the Parameter which would then be sent back to me with the Webhook. But, try as I might, I cannot find anywhere that lets me enter Parameters when using Charge the Current User on the Workflow for the Stripe Payments. I feel like I’ve missed something fundamental.

I’m using Stripe by Bubble. Do I need to install Stripe.JS2 or something instead? I’m already out of my depth with this but I can’t believe that what I’m trying to do is really that unusual.

I’d really welcome any suggestions.

All the best

1 Like

If you use the api connector you can pass metadata to the stripe api Stripe API reference – Metadata – curl

I don’t think any of the Stripe plugins allow you to pass metadata into the call (certainly the Bubble built one doesn’t)…

Which is one of many reasons I find it simpler and more effective to use the API connector instead (Stripe’s API is simple to use)…

1 Like

You should get the payment intent ID back from Stripe after the ‘charge the current user’ ?

Store that by referencing the step so you can find whatever it is you are processing later.

When the intent is captured the charge successful webhook should have the Id. It will be PI_xxxxxx.

Hi guys,

Yes Nigel, I´m doing that, BUT, the action that you mention wich register the paymet_intent_id only happens when the user comes back to our page redirected by Stripe.

If a user pays and leaves the page that action is not happening.

Adding to that, the webhook is faster than executing the action of register the payment_intent_id so I have to schedule a BWflow a few seconds after the webhooks arrives.

Would be better to have a way or an option to capture this payment_intent_id and not relying that the user comes back to our app.

Did you find any other solution?

Just use your own API calls instead… it takes 2 minutes to set up and is far more flexible than the Bubble Stripe plugin.

then you can do whatever you want/need to do without being restricted by limitations in the plugin.

Hi Adam, you´re right, I´m doing tha from my backend, to create checkouts, you have to create prices, payment links, etc. But then you have to archive those prices when you are selling “one time products”, the function “charge the current user” do this all automatically, is easier and don´t have all those API Calls from the front.

I wouldn’t use Stripe Products…

Just create the prices in the API Checkout Session call dynamically (just the same as the Plugin does - it’s the same thing)

It’s literally no more difficult than using the plugin, except you can do whatever you want (i.e. pass metadata into the call to retrieve in your webhooks).

For payments links generated from the backoffice of our application I could not find any other way to solve this feature. Always Stripe asking for a product and a price for that product, maybe I misunderstood the documentation.

Could you please share how would you do it?
Endpoints to use, or a simple step by step would be nice.


Ahh. perhaps I misunderstood what you’re asking?..

This thread was originally about retrieving data from a checkout session created with the Bubble plugin (and the responses were about creating a Checkout Session with your own API call instead)…

But it appears you’re asking about Payment Links? correct? (you didn’t mention that in your first post, but you have in your second post).

In which case you’re correct… there is no way to use Payment Links without using Products that already exist in your Stripe account (as far as I know).

Oh yes Adam, sorry, my bad, maybe it was not the main conversation.