#mark-reckard_docs
proud flameBOT
👋 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/1470432671178948781
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
cyan raft
Hi there 👋 my understanding is the same as the way you read it, that all parts of the balance need to be zero. That being said, this sits like right on the intersection of what my team is familiar (rejecting the Account object via our API), and what our Support team is familiar with (exactly what state accounts need to be in to be rejected).
Can you tell me a bit more about your usecase? Rejecting an account is a pretty rare action from my understanding. Are you looking into handling this in a one-off fashion, or are you looking at coding this flow?
keen dagger
We're looking at coding the flow. We're doing some work to harden our security and trying to see what is possible. I had a previous thread in this Discord about our plans going forward: https://discord.com/channels/841573134531821608/1465757480817524738
Basically, we have a button in our app which admins can click that "marks as fraud". Our plan was to attempt to programmatically refund everything back to zero and then reject.
cyan raft
Gotcha, yeah that makes sense
keen dagger
Yes this is ideally pretty rare, we've just run into a bit more of it recently, so we're trying to harden our approach to account security.
I think my confusion comes from the fact that in some places in docs it refers to "balances" (plural) and in some places it refers to "balance" (singular) and in an api call I can see a negative pending balance, but in the platform dashboard I can see a 0 total balance on an example connected account.
cyan raft
Yeah, that's fair. I'm not 100% certain, and as you mentioned I'm not able to test either, but my understanding is that all parts of the balance need to be zero. It may be worth trying to double check that with my colleagues in Support though:
https://support.stripe.com/?contact=true
keen dagger
Actually, this does not appear to be true: "in an api call I can see a negative pending balance, but in the platform dashboard I can see a 0 total balance on an example connected account" . It was intially true, but it appears that the negative balance I was seeing in the API is now reflected in the Dashboard, it was just delayed by some amount of time.
Another related question you may be able to answer: in the Refund docs there is a parameter that can be passed "refund_application_fee" https://docs.stripe.com/api/refunds/create#create_refund-refund_application_fee. it is not required, but it appears from my experience that it defaults to "true": ie when I refund a charge with reverse_transfer without passing refund_application_fee, it refunds the entire original amount from the connected account. Does it indeed default to "true"?
proud flameBOT
cyan raft
Hm, do you have an example request showing that?
I'm seeing that it has to be explicitly set to true here.
keen dagger
Here's a request I made: req_IM1bSbE3UuO8pc. We do not explicitly pass "refund_application_fee" anywhere in our application, but we do reverse_transfer by default if that is relevant.
So in this test charge/refund: I initally charged 5001 cents and after the application fee, 4836 was pending in the connected account balance. Then I refunded the charge with reverse_transfer and 5001 was taken out of the account, leaving a negative balance of -165 cents.
lavish wagon
It took me a bit with testing but I think I understand this now: this param determines whether the application fee portion of the fee comes out of the platform or connected account's balance. By default it is false, which means the funds come out of the connected account's balance. If you had had it set to true, the refunds amount to the customer would have remained the same, but only 4836 would have left the connected account's balance to do so (165 coming from your balance).
keen dagger
Ok I think that makes sense, and probably solves our problem. I will test that out today and chat with my team about that strategy. Thanks again!