#neil_error
hard moonBOT
👋 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/1326632419733803049
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
stiff root
Hello there
Hmmm what is AddVerification doing?
We don't have an "Add Verification" endpoint so that seems to be your own code?
empty timber
oh sorry i was going to add that code but ran out of lines
stiff root
No worries
empty timber
func (ss *StripeService) AddVerification(accountID string) (*stripe.Account, error) {
accountUpdate := &stripe.AccountParams{}
accountUpdate.AddExtra("additional_verifications[document][apply_to][]", "representative")
// disable payout if not validated
accountUpdate.AddExtra("additional_verifications[document][upfront][][disables]", "payouts_and_payments")
// add document check
accountUpdate.AddExtra("additional_verifications[document][requested]", "true")
// require live document capture
accountUpdate.AddExtra("additional_verifications[document][require_live_capture]", "true")
// add selfie check
accountUpdate.AddExtra("additional_verifications[document][require_matching_selfie]", "true")
return account.Update(accountID, accountUpdate)
}
Ah okay do you have an example account update request ID that you saw take a long time?
empty timber
give me 1min to double check
stiff root
Off the top of my head there isn't really a reason I can think of so an example would help to look at.
empty timber
is the best way for me to find the request from the Developer tab in stripe dashboard? Use filter for Method = POST and API endpoint = /v1/account?
stiff root
The endpoint is /v1/accounts/:id
And you would need to filter for outbound Connect requests
empty timber
Okay, im fairly sure i have the right filters, but cant find the request 😦
stiff root
Can you share that Connected Account ID?
empty timber
any concerns with sharing it here publicly? I guess no one can access it wihout credentials
stiff root
Correct, all of these object IDs can only be accessed with your secret key
So never share that
empty timber
acct_1QeoyjC0SaCUEMki
stiff root
The IDs themselves aren't sensitive
Okay looks like https://dashboard.stripe.com/logs/req_2qcXNmvalXHlPn is an example
Give me a moment to look at our logs for that
Have you been running this flow a bunch of times on this account?
Is that the reason I see so many sequences of the account being auth'd and then you make this update request?
(Like are you doing that for testing purposes and this is expected?)
empty timber
doing it multple times because it keeps timing out
stiff root
You shouldn't need to reauthorize though
empty timber
its actually our customer tht keeps trying to connect their account which is causing the multpel requests
stiff root
Ah they don't realize they are already connected
empty timber
exactly^
stiff root
So they go through the flow again
Hmm okay
And this is just happening with this account or multiple?
I do see this request taking a long time
empty timber
and they reason thye dont realize they are conencted is because our service terminates early because of the timeout so we are never able to save the conencted status
stiff root
I'm really not sure why at the moment tbh
empty timber
its with multiple accounts, but its intermittent. We definitely have accounts that get connected without any problem
stiff root
Interesting
empty timber
separately (and less important), am I just doing something wrong that I couldn't find this request when I searched the developer dsahboard.
stiff root
Hmm no, I don't see it there either when using /v1/accounts/acct_1QeoyjC0SaCUEMki as the path -- but if I do /v1/accounts/:id as the path I do see it there... I'll flag that internally, seems like a bug in our filter there
empty timber
sounds good not urgent.
it sounds like based on your initial findings that if I were to increase the timeout even further this might actually work?
by "work" I mean not timeout
stiff root
Yeah that request seemed to take nearly 30 seconds, which is quite surprising to me.
empty timber
I do see this request taking a long time
ooof... we would really have to increase the timeout
stiff root
Ah wait wait, no It was only just over 15seconds
There was some other stuff internally that happened after that response point
So for this specific request you would only have to increase your timeout a little bit.
So in the short-term I would recommend doing that, however I'd also like us to look into this more from our end for why this is taking so long.
hard moonBOT
Hello @empty timber, we have sent you a direct message, please check it at https://discord.com/channels/@me/1326640130097942609
- 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
stiff root
Can you use that DM that you just received and send us an email to open a ticket and include the above request ID so that we can take a deeper look?
empty timber
done, thanks for taking a look