#kevinx9999_best-practices
edgy boltBOT
👋 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/1290424643228008524
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- kevin_dispute-accountsupport, 6 days ago, 64 messages
civic wharf
Hello there, we have an issue here that webhook feedbacks were sent mutiple times and it triggers mutiple duplicated actions such as create a new customer record in the database, what is the best practice to prevent this behavor, thanks
crisp quartz
@civic wharf Hello! Can you please provide a clear example Event id so I can have a look?
civic wharf
Yes, here is the id evt_1Q2aM0HPFOtcTjmBFr6qMlgN
there was a checkout.session.completed successful on Sep 24th, then in the next few days, we kept getting feedback from checkout session completed, the logic here we are using is to create a new customer once the checkout session is completed, so it created a lot duplicated customers
crisp quartz
Your own webhook endpoint errored here. We never got a 200 saying you got the Event, so we retried over and over as expected
civic wharf
it was 200 on Sep 24th when the transaction happened, that's when we created a customer, after that, all these retries won't be able to create correct customers, so they just created some useless records and return status 500
crisp quartz
no, that's what I am saying. You think it was 200 but it wasn't. The first attempt we did was a 500 too. You seem to have 2 separate WebhookEndpoints with the same URL. So we would have delivered the same Event to each one even if it's the same URL. Maybe that's your bug/what you are mixing up
civic wharf
First, we don't have endpoints with same URL, second I see the feedback events shows different amount charges etc from another different URL too
crisp quartz
ah my bad the middle of the URL is different. So yeah we're back to what I said earlier. every attempt failed on our end from what I can tell
It is totally possible for your code to think it succeeded and for ours to think the request failed. If we think the request failed we will retry.
civic wharf
if you look at the image I sent earlier, all those are for a single transaction which was succeed on Sep 24th
it was green with status 200, then later days, it just got different charges with different data etc.
crisp quartz
I don't really get what that image is about though. I'm sorry I'm really struggling to follow your train of thought. What does that mean "it just got different charges with different data". That would mean they are for different Events with different ids evt_123 and evt_ABC
Sorry but I am looking at our internal systems for the specific Event id you mentioned and I am certain that one of your endpoints returned a 500 for each attempt
civic wharf
ok, seems the webhook events were sent back to wrong endpoints all these time, even though we have different endpoints
crisp quartz
We send the Events to each WebhookEndpoint subscribed to that specific type
civic wharf
ok let me clarify, if two endpoints subscribed to the same event like checkout.session.completed , Stripe sends the events to both endpoints, no matter which endpoint Secret we are using?
it just blasts the events to all endpoints if they sub to it, no matter?
crisp quartz
yes, that's exactly how WebhookEndpoints work. Your mention about the secret doesn't make sense to me. The secret is only used on your own server to verify the signature of an Event delivered to your WebhookEndpoint
So yes we "blast all endpoints that subscribe to a certain Event type" because that's the point of the feature
civic wharf
ok, thanks for clarifying it.
so there is no need to make mutiple end points for the same Type of events for different products or services since it is not distingushed
No wonder it feels weird here lol
so what is the best practice to differentiate different product or service after checking out, what should be the design here, using Meta data?
crisp quartz
yes metadata likely
civic wharf
Is there any other approach to achieve it? any official doc that I can follow? thanks btw
crisp quartz
Sorry you are really into the weeds of your own business. I'm kind of guessing what you mean when you said "differentiate product or service" like those are things about your own implementation
But setting the right metadata on the Checkout Session at creation is a reasonable approach if you want your handler(s) to know where the Checkout Session comes from. Or looking at its line items, see https://docs.stripe.com/expand#includable-properties
civic wharf
I assume there are lot other businesses selling different products or services and you probably saw tons of examples on how to distingush them and record them, that works well with Stripe API, that's why I was asking
crisp quartz
Sure, what I said above are two of the potential approaches
civic wharf
ok, thanks, one more quick question, after checkout.session.complete, is there any other events that we can use for this purpose? to tell the difference between products and services
why do people needs different end points then, just to handle different event types?
crisp quartz
why do people needs different end points then, just to handle different event types?
most people never have multiple WebhookEndpoints.
And I don't really get your question it looks like the same as the first two questions I replied just above. You aren't clearly defining what you call "different products and services".
If you mean the exact Price and Product ids in line_items then you would listen to checkout.session.completed and then you would retrieve the information in the API via https://docs.stripe.com/expand#includable-properties
civic wharf
> why do people needs different end points then, just to handle different event ...
Great, thank you!! Just to make sure, if Stripe gets a status 200, there won't be more feedbacks or retries right?
crisp quartz
for that specific WebhookEndpoint that's correct! *
I put the * mostly because it's possible for us to re-send the Event anyways. It's covered in https://docs.stripe.com/webhooks#handle-duplicate-events
civic wharf
Handle duplicate events
Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by logging the event IDs you’ve processed, and then not processing already-logged events.
First Stripe's event ID is unique right? if the second events come in with different ID, how do we safe guard it since the ID is different
crisp quartz
😅
civic wharf
that would create duplicated actions on our end based on events we received from Stripe
crisp quartz
Sorry I feel like you might have rushed into reading this and forgot the whole context
You came because we sent the same exact Event multiple times. It has the same Event id (evt_123) and it was due to retries because your own endpoints errored.
You asked if as long as you reply a 200 every time we won't retry and I mentioned an edge-case and linked you to the docs for it. That is the same context, it would be the same exact Event with the same exact id evt_123
civic wharf
😆 Got you, so we have to record and check the event ID, ah that's a little bit pain
crisp quartz
👍
civic wharf
Thanks @crisp quartz !! Have a good day there!