#maria_api
wintry totemBOT
👋 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/1219278050257145969
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
orchid crestBOT
ashen coyote
Here's the log in question where you can see that the account destination matches
sacred cipher
Hi @ashen coyote can you copy/paste the Request ID from request_log_url in your screenshot, the part that starts with req_?
ashen coyote
req_OJEV8LOQvb7Rmm
sacred cipher
That request is several months old, the Connected Account wasn't connected to your Platform at the time that request was made. Because of that, the request to create the Transfer failed as the two accounts were associated with each other at that time. Are you able to make Transfers to that account now?
ashen coyote
oh interesting -- it's kind of the opposite. the transfers used to work (e.g. on April 4, 2023 req_nRUVwsJ1tm40Yx) and then stopped working. the most recent one to fail was March 4, 2024 req_hPkq2p40I4ncJr
sacred cipher
Is the Connected Account disconnecting/reconnecting to your platform?
ashen coyote
how would i be able to tell?
sacred cipher
Hm, it doesn't look like you have a webhook endpoint set up listening for events related to that. If you look at the Connected Account's page in your dashboard, do you see Events mentioning authorizing or deauthorizing?
The first two types mentioned here:
https://docs.stripe.com/api/events/types#event_types-account.application.authorized
orchid crestBOT
ashen coyote
Yeah our setup is kind of weird. Our app initiates the payouts directly rather than having stripe drive that logic.
Let me look into the Events question but at first glance, I don't see any Events on the connected account page
sacred cipher
Based on what I'm seeing, that account connected to your Platform more recently than when you tried to create on March 4th this year.
ashen coyote
Hmm ok let me look through some logs and try to figure it out. It's possible the user tried reconnecting their account at some point but I'll try to dig through the logs in the next few minutes
Ok so on April 5, 2023 (the last time a transfer successfully happened) the acct number was acct_12Ld01Pw6WPTFYhSZvaR (tr_0Mtgul01Pw6WPTFYs6qr4kJY). At some point after that, the user must have changed their account number to
acct_1Gi8gzAUR2M2lg9g, which is what it is today.
What I don't understand is why on March 5, 2024 (req_hPkq2p40I4ncJr) the POST body was using the new account number (acct_1Gi8gzAUR2M2lg9g) which is what currently matches the connected account, and it was still returning a "No such destination" error
worldly sky
👋 stepping in
At some point after that, the user must have changed their account number to
acct_1Gi8gzAUR2M2lg9g, which is what it is today.
To be clear, we don't "change account numbers" -- this sounds like within your own database tracking you switched a reference for the account of one of your users?
What I don't understand is why on March 5, 2024 (req_hPkq2p40I4ncJr) the POST body was using the new account number (acct_1Gi8gzAUR2M2lg9g) which is what currently matches the connected account, and it was still returning a "No such destination" error
As noted above, that account wasn't actually connected to the platform at that point.
So that is why it returned that error