#kafkaesque_connect-refunds-balances
robust flaxBOT
👋 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/1500927589919752232
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
ocean berry
The idea is to issue a transfer reversal if the connected account does not have the funds. We have connect reserves, which means our accounts are capable of going negative. This places a "hold" on the funds. We monitor the account's balance, and once it becomes positive, we transfer the funds back to the account and issue the refund. We're thinking it can go positive either via auto-debit triggering or them just making more transactions
Does anything here stand out as just an incorrect usage of transfers, slash will the API disallow this flow?
Also if there's a better place to ask these sorts of questions I'm happy to be redirected 🙂
thorny moon
Our canonical guide for issuing refunds for destination charges is https://docs.stripe.com/connect/destination-charges#issue-refunds
In that case you can reverse the transfer as part of the initial refund creation. If you already have reserves set up, this should use them automatically.
In cases where the reserves are not sufficient you can also enable debiting the Connected Account's external bank account, if you meen the requirements we document here: https://docs.stripe.com/connect/account-debits
ocean berry
Our canonical guide for issuing refunds for destination charges is <https://docs...
Yeah, I understand this. But this isn't really desirable, right. Just thinking through the fraud case of someone using refunds maliciously, putting their connected account in the negative, and then just disappearing
thorny moon
These requests are triggered by your integration so you would have control over it
Can you explain what is not desireable here?
ocean berry
So, what is not desirable is
We issue a refund that moves the money out of our platform, and leaves the connected account in the negative. We no longer have access to the money that was refunded, and the bank linked to the connected account does not have the funds, so debiting fails.
In this case, now our platform essentially loses the money that was refunded.
That's why I was mentioning a slightly more convoluted flow that relies on transfers. We use transfers to put a hold on the account. In this instance, their connected account balance has gone negative, but we haven't refunded the money yet, just transferred to our platform balance. We wait until money comes back into their stripe connect balance either via auto-debit or through other charges they do on our platform. Once their balance is positive again, we issue the refund. In this case, the money never leaves our platform until we're sure the connected account has the funds to cover the refund in full
thorny moon
That is an approach you can take but I thought you said you had Connect Reserves such that you would have the available funds to issue the refund?
ocean berry
Well, it's not about not being able to fund the refund, its about avoiding a malicious actor using refunds
Say someone connects their bank and a card, issues a charge to themselves, and refunds it
thorny moon
The flow you are describing is focused on moving the money around. If you are concerned about malicious actors I would try to front-load that investigation, e.g. more due diligence before even considering issuing a refund
ocean berry
But we're trying to allow our connected account users to self-service refunds.
thorny moon
Yeah that's a tough line to walk
robust flaxBOT
ocean berry
I mean, if nothing stands out technically about the approach I suggested, that's fine with me. It has the downside that it makes refunds much slower for our customers' customers and down the line i know stripe has some minimum balance stuff we can roll out
but as long as there's no gotchas that would prevent that flow from working im happy to implement it
thorny moon
Essentially there is nothing "wrong" or "bad" with your approach. It just doesn't leverage all the tooling we've implemented to try and make it a more simple approach. But that tooling expects that you can trust your Connected Accounts to be making these requests in good faith
My concern with the delay is that it might result in the end customers opening Disputes
Which will automatically pull the money out and require a separate process
ocean berry
cool. ive noticed that with connect reserves, after 180 days, stripe transfers money back. that's okay, i think i might just implement it such that after 90 days, refunds fail. that shoulve been more than enough time for the connected account to have been auto-debited. we can also have ux telling them to make sure to have funds in the bank linked to their connected account
i hear ya on the disputes.
thorny moon
Depending on how the refund process is communicated to the end customer, you might be able to avoid that (the disputes part).
ocean berry
yeah. and if it starts becoming a problem we can start rolling out balance minimums
thorny moon
That's another way to approach it. Require a certain minimum balance in the Connected Account's Stripe balance to cover refunds.
ocean berry
cool, thanks for your input. have a good one
thorny moon
You too!