#taylorcooney_api

1 messages ¡ Page 1 of 1 (latest)

tribal cipherBOT
#

👋 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/1265350966488858655

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

livid vale
#

I'll add in terms of "what have you already attempted?" that our typical course is to counter the dispute. However, I am starting to notice that we are out of pocket during this process.

When a refund occurs for a destination charge, Stripe will first debit our platform account to immediate cover the funds and then initiate a second debit on the destination account to recover those funds on our platform.

This seems to be different with disputes, where when a dispute is opened a second debit is not initiated on the destination account (mainly because the dispute is still open).

#

I am also now noticing that when a dispute is "lost", the transfer payment is still intact -- meaning that the funds are not reversed back to our platform account.

little remnant
#

Hello, good question looking in to this. I know with Refunds there is a param to automatically reverse the transfer. I forget if we have something similar for disputes. If not, you can try to manually reverse the funds or debit the account, but I will see if there is something easier

livid vale
#

Thanks my dude

#

I am just realizing we are out of pocket for a couple hundred dollars for lost disputes, while the destination account that received the original transfer still has their payment

#

Looking at our code, we have the following for refunds:

# 
::Stripe::Refund.create({
  payment_intent: refund.charge.processor_id,
  amount: amount,
  reason: refund.reason,
  reverse_transfer: true
})
little remnant
livid vale
#

Ugh

#

How did I miss that in the docs face_palm

#

Thanks for linking that

#

I guess we will need to: 1) update the logic based on the docs and 2) initiate a manual reverse transfer for disputes that we have lost over the last few months to recover the funds

#

Because, correct me if I am wrong - if you look at that related request ID from my initial message, we are out of pocket for that?

#

Here is another related ID: tr_3P0pAiKYTiCt9KzS0oef9TbZ

little remnant
#

And if the account doesn't have the funds on it any more because they have been paid out, you can try debiting the account. If your connect setup doesn't allow for those account debits, the two most common ways I am aware of to deal with that are:

  1. Creating a Customer to represent each connected account, save a payment method for them, and charge it like a normal Customer
  2. Withold sending funds for future payments until you have recouped the funds that you are out
    https://docs.stripe.com/connect/account-debits
#

Looking in to those

livid vale
#

Would love your eyes on this quickly regarding the source transaction (and dispute outcome), and the destination payment (py_1P0...)

little remnant
#

So yes, you are right that the funds for those came from your platform account's balance because they are destination charges. Is there something specific about that that you are trying to understand for these two disputes?

tribal cipherBOT
livid vale
#

What I wanted to know specific about those two disputes is what we should be doing about it so we are not out of pocket

#

From this conversation, my understanding is that we will need to: 1) update the logic based on the docs and 2) initiate a manual reverse transfer for disputes that we have lost over the last few months to recover the funds.

Does that sound right @little remnant?

stiff elm
#

That's correct