#gizmo-paymentintent-id

1 messages · Page 1 of 1 (latest)

plain citrus
#

You control the code that creates the PaymentIntent so you can get the id from that code anywhere you need it

storm pendant
#

Thanks, does this paymentElement have an id once it's created? const paymentElement = elements.create('payment');

plain citrus
#

you likely are misunderstanding the flow completely

#

this does not create a PaymentIntent at all, this just prepares you for mounting our UI element called a PaymentElement

storm pendant
#

I have this


        // Create and mount the Payment Element
        const paymentElement = elements.create('payment');

        paymentElement.mount('#payment-element');```

At what point can I get an id corresponding to the payment intent so that when the payment is successful and redirects and I am provided with the payment intent id as a parameter I can look up what was in the order?
plain citrus
#

nowhere in any of this really

#

the PaymentIntent id is created server-side

storm pendant
#

I have the client secret from the payment intent i created server side. Should I be saving that and using that to look up the order details instead?

plain citrus
#

Yes, or store this information in a browser session/cookie

storm pendant
#

I see, thanks. I thought I wasn't supposed to store the secret so I was looking for an id.

#

If i were to put it in a session wouldn't I not be able to process the order via the webhook?

plain citrus
#

If you get an Event to your webhook endpoint, that Event already has the entire PaymentIntent in it including the id, so there's no reason to look for the id in that case

storm pendant
#

Right but since I can't save all of the order configuration data synchronously I have to save it all before there is actually a successful payment. So I need to save the order data with some way to identify the payment so that when the payment goes through I can process the order.

plain citrus
#

why can't you save the data synchronously? I don't follow
Your code prepares an order, saves the information "somewhere" like your database, and then your create a PaymentIntent with the order id in your system as metadata and then when you get events you can lookup the metadata and map it to your order

storm pendant
#

Oh, so I can pass my pending_order_id to Stripe when I create the PaymentIntent, and then I can access it from Stripe's payload both after the successful payment redirect and upon the webhook invocation?

plain citrus
#

yes!

#

that's what I'd do at least

storm pendant
#

It sounds like you're saying I'll need to make an additional call to Stripe to lookup the order id in the metadata, is that correct? If so, would I be better off saving the PaymentIntent's secret on my pending_order so that I can look it up upon the redirect or webhook invocation without having to then make an additional call to Stripe to fetch my order id?

plain citrus
#

you get an Event, the Event has the entire PaymentIntent object including yuour metadata

storm pendant
#

Will the entire PaymentIntent object be present upon the redirect after successful payment?

#

Or only in the webhook payload?

plain citrus
#

only in the webhook payload

#

you talked about webhook

#

for the redirect you use a browser session/cookie and you know who this customer is and what their order id is

storm pendant
#

Because I was advised the best thing to do is create an idempotent process whereby I can either process purchases right after a successful redirect or when the webhook comes in if they haven't already been processed.

#

Do both the redirect and the webhook payload contain the PaymentIntent secret? If so, can I just save that with the pending order so that I can lookup the order via the PaymentIntent secret without having to do it different in both scenarios?

#

Hello?

plain citrus
#

hello?

#

Sorry there are lots of other people asking questions

storm pendant
#

No worries, I just wanted to make sure I was still connected. I really appreciate your helping me with this.

plain citrus
#

Do both the redirect and the webhook payload contain the PaymentIntent secret
Yes but that's really not looking at it right. In the webhook handler, the client_secret is meaningless, you have the entire PaymentIntent object, with the id, the metadata, etc.
In the redirect, you're in a browser, you know who that customer is, you have a cookie/browser session in which we can store everything you need

storm pendant
#

Got it, thank you koopajah. I have to run but I will be back later with more questions. 🙂