#dmitry-zip_webhooks

1 messages ¡ Page 1 of 1 (latest)

lean trailBOT
#

👋 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/1306358124629987349

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

hasty oxide
#

This seems to be the case for all requests that result in 'invalid_request_error', as well as some other errors such as: 'idempotency_key_in_use', 'rate_limit' and some others
My impression is that we are only getting failed payments webhooks for those payments that were declined by the issuer bank. However, if the error happened before Stripe had a chance to forward the request to the bank, then we are not receiveing webhooks. Can you please confirm this?

last sundial
#

Yep yep, that is the expected behavior here. Those errors aren't about the payment failing per se, they are about the API call failing.

#

The error codes they return should come back to your code that makes the call, so that is where we would expect you to handle that error. Because your server is making these API calls, it already knows about the failure without getting an event about the failure. So in theory the server that gets these kinds of errors can react or notify your other systems accordingly.

hasty oxide
#

What about the cases when our system loses connection to Stripe due to a network error before it can get a response? Is there no webhook that can notify us of those 'non-payment' error codes?

last sundial
#

No, but there is still a lot working for you to keep a consistent state in that situation so you can still have an accurate picture for what has happened:

  1. You can retry the call with the same idempotency key, that would mean that we would either create the intent for the first time or do nothing and simply send you the original intent or error response that you should have gotten the first time. Our client libraries actually have built-in retry logic that you can turn on to try this automatically.
  2. Webhook events, you will still get webhook events for an intent being created and then events for it succeeding, failing, or doing whatever else it may do as part of the API call.
  3. Any intent that is created will be immediately available in the payment intents list call, so your integration can try listing payment intents for the customer before trying to create another.
hasty oxide
#

Okay, got it, thanks!