#velveth_56818
idle hamletBOT
Hello! We'll be with you shortly. 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.
- velveth_56818, 3 hours ago, 17 messages
slate jackal
Hi, to clarify, your issue is not being able to receive issuing_authorization_request webhook event? Was the event generated in the first place?
lone trail
Thats correct
and it wasn't
According to the docs, we can only have 1 webhook listening to the issuing_authorization.request event at a time, so it's fair to assume that in order for these events to get forwarded to my CLI, I need to disable the currently active webhook.
Note that the webhook is currently disabled, but my stripe CLI is still listening for this event. We can see here that the event is still never forwarded to my local listener. That is the problem.
The 2nd issue, which is less impactful (but still a concern), is that this authorization was automatically approved because the issuing_authorization.request event was never created. I'd like to set this issue aside for now so that we can focus on our main concern.
The main concern being: issuing_authorization.request events are not being forwarded to local listeners for connected accounts.
slate jackal
Yes but first let's look at whether it wasn't generated at all. If it wasn't generated then no listener, local or not, could ever receive it
If you look at your Dashboard, you can't see any event?
lone trail
the event was generated
slate jackal
Ok, can you give its id? evt_xxx
lone trail
https://dashboard.stripe.com/acct_1Nwq0CCLHaT4voF6/test/issuing/authorizations/iauth_1OelnXCLHaT4voF6VGQWVN12
https://dashboard.stripe.com/acct_1Nwq0CCLHaT4voF6/test/issuing/authorizations/iauth_1OelooCLHaT4voF6eqpnSX7a
There is an authorization created event but not an authorization request event. Perhaps, the ideal solution would be to give precedence to the local listener over the configured webhook endpoints
According to the docs, they can only have 1 webhook listening to the issuing_authorization.request event at a time, so it's fair to assume that in order for these events to get forwarded to their CLI, they need to disable the currently active webhook. They do that here before the next authorization shown below:
https://dashboard.stripe.com/acct_1Nwq0CCLHaT4voF6/test/issuing/authorizations/iauth_1Oi0mxCLHaT4voF6T4o1IjC3
Note that the webhook is currently disabled, but their stripe CLI is still listening for this event. They can see here that the event is still never forwarded to their local listener. That is the problem.
The 2nd issue, which is less impactful (but still a concern), is that this authorization was automatically approved because the issuing_authorization.request event was never created. They'd like to set this issue aside for now so that we can focus on their main concern. For some added context, they have also tried the same thing with a slightly different CLI command. Both of the following commands have the same issue that I see above:
stripe listen --forward-to localhost:50231/api/stripe/issuance/real-time-authorization/5 --events issuing_authorization.request
stripe listen --forward-connect-to localhost:50231/api/stripe/issuance/real-time-authorization/5 --events issuing_authorization.request
Note that one uses --forward-to and the other uses --forward-connect-to . Either way makes no difference, except I would expect --forward-connect-to to be the correct approach for their use case.
The main concern being: issuing_authorization.request events are not being forwarded to local listeners for connected accounts.