#masonhale_api
shrewd summitBOT
đ 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/1235301431276208309
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
earnest doveBOT
nimble oak
Hello
So the question here is how did tr_1PBSek2HDRoZ2HuJyfMhKgoG originate?
That Transfer was actually an Account Debit.
Where you create a Transfer on your Connected Account to move funds to your platform
astral dawn
Essentially, yes. I assume it is related (maybe indirectly) to the request req_agcGXZqkX7VMPd
nimble oak
https://dashboard.stripe.com/logs/req_X1jjXjH7BmOPp2 was the creation request for it
It does have the same amount as that failed refund request
But it was an explicit request made by your code. Perhaps you have logic set up to create an Account Debit if there is a dispute?
astral dawn
Ah, ok, I think I know what may have happened. We use a "separate charge + transfer" method of capturing payments. So, in a refund scenario, we reverse that process. We use account debit so that our customers can (optionally) issue a full refund including transaction fees (which we do not refund, as Stripe also does not refund these). I think in this case, the first step of the two step process -- debiting the funds from the customer's account -- worked, but then the attempt to issue a refund against the charge failed, but our code did not catch that failure for some reason. I'll review the code, especially for recent changes.
But, just checking, does this hypothesis sound reasonable/feasible/likely to you?