#mrdanvant_webhooks
rain arrowBOT
👋 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/1428399974160404652
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
coral dirge
Hi Guys, we are receiving a number of webhooks messaged from connected clients, but from payments that have been initiated via one of their other apps
crude ridge
hey there, taking a look at this, but for accounts connected to multiple platforms this is expected
Do you have a specific question about this event/payment?
coral dirge
ok but the issue it how does a payment that is not initiated by us want to send us webhook messages, and how does it know what our webhook endpoint is
then because we are not expecting their message we respond with a 400 which means you then try and resend it again and again
crude ridge
In this case that checkout session was from a payment link created by the connected account itself, so this would happen even if there were no other platforms connected
this is expected behaviour since your connect-type endpoint is subscribed to checkout.session.complete events, you get all of those events that occur on all of your connected accounts, regardless of whether your platform was involved in the checkout session or payment link creation
I'm inferring that for your purposes you only need the events associate with checkout sessions you created on the connected account, is that right?
coral dirge
hmm ok, so is there something we need to change to prevent this from happening as we do not want to keep getting webhook retries from unrelated payments
crude ridge
There is no way to not get them outside of removing the event type, no, but there are options about how you handle them depending on what you need
coral dirge
yes you are right in your assumption, we do not want to know about any other payments other than the ones we initiate
crude ridge
for example, why do you respond 400 on this delivery? What is failing in your endpoint to cause that?
So one way you can manage this is by setting metadata on the checkout session, for example metadata[from_my_platform]=true and then during processing you can check that metadata and dismiss those without that set as they happened some other way
coral dirge
it fails because it does not match any with any client data that we are waiting for.
crude ridge
does not match any with any client data that we are waiting for
Based on what kind of check?
coral dirge
im guessing some form of property id because the response we issue back to the webhook is that the property is not found
crude ridge
Do you have any example checkout sessions / payment intents that are associated with your platform? I don't see any requests related to your platform in this accounts recent request logs
coral dirge
let me see what i can find for you
crude ridge
Ah here I found one on oct 11: cs_live_a1g6nqnIMeQwzx6NDeDF8mLHytNHsdtS0UOPIzaWsrBnGK9kScXXfN37hE
other than that one, it looks like no sessions (from your platform) since july
coral dirge
that cant be right
crude ridge
It may not be, and happy to examine any example you have to contradict that, but its besides the point of the events and metadata here
coral dirge
digging something out for you
crude ridge
In this session creation i see you're already using metadata to set a company name and payment intent description with some kind of ID (a booking reference maybe?)
coral dirge
yes thats right
crude ridge
So what I'm suggesting is adding another metadata key/value to explicitly indicate your platform here, which your endpoint can then check and dismiss events from sessions created other ways
for those events you'd respond with 200 and ignore, optionally keeping a thin record on your end of the session id/event id if you want
coral dirge
so i guessing the real issue is that we are responding with a 400 so you guys keep trying to send... what response should we be giving so you do not retry
crude ridge
200
coral dirge
ok so respond with a 200 and ignore - thanks
coral dirge
becasue at the moment we are being bombarded with webhook retries
crude ridge
often this is misconstrued or misusedas a "success processing" indicator, but that's not how we treat it
coral dirge
especially as we have about 95 connected accounts
thanks for you help... i think we have a plan now, to be able to manage, respond and ignore 🙂
bye for now 🙂
one thing i dont understand
why it is only for rendom payments and not every payment
rain arrowBOT
crude ridge
why it is only for rendom payments and not every payment
Can you clarify the question here and/or share specific example of what you mean and my colleague will be happy to help
coral dirge
for one particular client they have lots of payments initiated from their side and of those maybe 6 have then gone onto to send webhook updates to our server
lament drift
Okay so first, the Webhook was sent but failed... so it is being sent.
Can you provide the Event ID in text here so I can look at the failure
coral dirge
but it failed because we were not expecting it so we responded with a 400
evt_1SIpb9GPaSdSjI6vrgy36fcO
lament drift
I'm not sure what you mean by that?
There was a Checkout Session completed... why would you not expect a Webhook?
coral dirge
the payment was initiated by another app or service the clients also uses their stripe account on, but it responded to our webhook server for some reason
we didnt intiate the payment
lament drift
Ah I see the confusion. Yes this is expected. If you listen for Connect Webhooks then all Events (of the types you are listening for) on your Connected Accounts will be sent to your endpoint, it doesn't matter what generated them.
So you could do something like adding metadata to the relevant objects you care about (like the Checkout Sessions you create).
Then you check for that metadata in your Webhook handler and decide how to handle the Event.
coral dirge
yes i get that sunthrider said that, but the additional confusion is why is it only random payments and not all payments
lament drift
That is the second time you have said that but you haven't provided any relevant example... what do you mean by "random payments and not all payments"? What is an example of that?
coral dirge
out of all these payments from the same client all of which NOT initiated by us, only these 2 random ones sent to our webhook
lament drift
Please provide specific Event IDs that I can look at.
Just sharing screenshots doesn't really help.
coral dirge
here also
ok sorry
here is an event id that did send to our webhook (payment was NOT initiated by us) evt_1SIpb9GPaSdSjI6vrgy36fcO
save client less than an hour later (again not initiated by us) but it did not send to our webhook: evt_3SIqD2GPaSdSjI6v1CuhiDse
lament drift
Thank you.
Looking
Your Webhook endpoint only listens for:
checkout.session.completed
payment_intent.payment_failed
So no other Event types are going to be sent to it.
coral dirge
ok thats makes sense now you said it 🙂
whats difference between succeeded and completed
coral dirge
LOL sorry... again you make perfect sense now you said it.. it has been a long day
so i guess the main thing if for us to better handle requests that do not interest us and respond to accept receipt but then ignore so you know it has been received succesfully and do not try and resend constantly
lament drift
Yep pretty much
coral dirge
thanks for helping to clarify everything Bismarck
lament drift
Sure thing!
coral dirge
Bye for now 🙂