#cristoffer_webhooks
wicked zincBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1326250348985192470
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
drifting escarp
Hello! For #1, it depends on your specific use case and business needs. There's no one-size-fits-all answer to that question.
For #2, in most cases yes, but be aware there are also other Event types for async payments via Checkout: https://docs.stripe.com/api/events/types#event_types-checkout.session.async_payment_failed
For #3, yes, it should always be there if it's present on the Checkout Session.
For #4 I'm not sure I understand the question, can you provide more details?
neon jungle
Hi, more details about question 4. I was thinking about use case when customer uses async payment method before session expires, but it fails after expiration time, in such case will session be expired/renewed?
Also more details about #1. I am creating session only, without creating payment intent before. I noticed that stripe creates payment intent while customer is trying to pay. I dont know if I should handle case when payment intent was created but customer somehow cancels payment or just wait for session expiration time?
drifting escarp
Oh, no, an async payment failure won't reactivate an expired Checkout Session.
For that last question I'm not sure what you mean. I think I need more context. What are you trying to do? What's your goal? What's preventing you from accomplishing that goal?
neon jungle
I mean, user can somehow cancel payment created for them? I am just trying to cover all use cases.
For now my flow looks like that.
- User picks products, quantity of these products, and creates order using button.
- My backend app is gathering all needed data and creating checkout session for this order.
- backend is returning url to payment on Stripe.
- User trying to pay
4a. successfull sync payment (I think i covered that by handlingcheckout.session.completed)
4b. checkout expires (I think i covered that by handlingcheckout.session.expired)
4c. async method was used and successfully ended (I think i'll cover that by handlingcheckout.session.async.payment.succeeded)
4d. async method was used and fails (I think i'll cover that by handlingcheckout.session.async.payment.failed)
On each event I am sending user appropriate email message. Are these events all that in general have to be handled? I was wondering also if customer can somehow cancel session payment on his own?
Even if the payment_intent.canceled event is emitted, session doesnt ends so probably it can stay unhandled, but when exactly it emits?
drifting escarp
It sounds like you're on the right track overall.
It's a good idea to handle all of those Event types, yes.
Customers can't expire Checkout Sessions on their own, no.
There are rare cases where a Payment Intent created by a Checkout Session will get canceled without the associated Checkout Session expiring. You can also listen for payment_intent.canceled and handle that if you wish (you could, for example, expire the associated Checkout Session if you wanted to). Entirely up to you.
neon jungle
Okey, I'll rethink it, thank you for your help 🙏