#Fossil
gusty peak
sour jay
Sorry, confusing. You're referencing a change unrelated to Payment Intents. I assumed you mean this change:
A PaymentIntent is no longer created during Checkout Session creation in payment mode. Instead, a PaymentIntent will be created when the Session is confirmed.
sour jay
I used to save this ID to my orders table and then use that to match incoming webhooks to confirm the payment. I see no unique identifier in the new format that I can use to match checkout payments to webhooks now.
cs_xxxwould be unique on creation. Then you can use the same ID from thecheckout.session.completedevent, which will also include thepayment_intentfield
crimson nimbus
This?
"id": "cs_test_a1IgPi2Dw29V9kf2IERgWokgf08nuSmKc1xP81tfMmAykS06i3KSVjvv9q"
sour jay
Yes
So that would be the 'order', then I guess when the .completed event fires you mark it as 'paid' and then reference the pi_xxx
crimson nimbus
Hmm. Okay so I need to listen for an additional webhook event, check for the cs_ value and then grab the pi_xxxx value.
I guess this is also why I see no Incomplete rows anymore in my Payments page in the Dashboard?
sour jay
Okay so I need to listen for an additional webhook event, check for the cs_ value and then grab the pi_xxxx value.
Recommendation is to always usecheckout.session.completedwith Checkout generally yes
I guess this is also why I see no Incomplete rows anymore in my Payments page in the Dashboard?
Correct
crimson nimbus
Ok. Because now I am just listening for payment_intent.succeeded to check if a payment was OK. Which contains the pi_ ofc
sour jay
Yeah I'd take the approach I mentioned as now you've no pi_xxx upfront
crimson nimbus
Yeah. Ok. Any reason for this change btw? Seems unintuitive to me 🙂
sour jay
It unblocks some other big features that are coming soon
crimson nimbus
Ok. And when a Checkout session is completed a payment is always 100% captured or should I then still check the payment intent too?
sour jay
WeChat is synchronous (same as cards), so that's fine
iDEAL is async, so the link I shared would apply
crimson nimbus
Okay. So I should listen to both and check the payment method to mark the order as captured for cards etc and only mark async payments as captured when they fire through async_payment_succeeded?
Or should I just add a field to my orders table for the cs_ value, then use the webhook to add the pi_ to that row and use another webhook to mark that pi_ as paid?
Kinda lost what the best course of action is here 🙂
I also see a "payment_status": "paid" in the session completed
sour jay
Must the order be created in your DB when you create the session?
crimson nimbus
Ehm. Thats how it works now. So I can match a payment to a user.
sour jay
Ok, fine. My recommendation:
- Create your Checkout Session.
- Create the order in your DB with the
cs_xxx. - Adapt your webhook handler like the link I shared, where you account for async methods (like iDEAL), by checking
payment_status. - In the webhook handler you can update the order status to reflect the
payment_statusand persist the associatedpi_xxxif you want. - Then for async methods, listen for
.async_payment_succeededevents and make another DB update.
crimson nimbus
Ok thanks. I will make that change.
Does Stripe remove old API versions at some point? Or am I good staying on this 2020 version for a while still.
sour jay
You can still use the OG version from 2011 today if you wanted 🙂
crimson nimbus
Haha ok thanks
I guess most people add the user_id to the Stripe metadata or whatever and then just wait for the payment intent webhook and only then create the whole order in DB?
sour jay
Yeah that's an option too
There's no right or wrong way. There are benefits to tracking the order before its paid too (like abandoned cart flows etc)
crimson nimbus
Ok. Cheers