#milan_90064

1 messages · Page 1 of 1 (latest)

vivid canyonBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

tame helm
#

Hello

short atlas
#

Hello again 🙂

tame helm
#

All other events have an accountId or onBehalfOf identifier on them. However, a dispute event doesn't have the connected account Id on it. Am I missing something? Otherwise, we can walk up from the payment intent Id to the account.
If the dispute occurs on the Connected Account then it will have an Account ID. However, if you are using destination charges then it would occur on your platform so yes you would have to look at the PaymentIntent and the transfer_data.destination

short atlas
#

It's coming in on the connected account and the account Id is null on the stripe event. All other events don't have that issue.

tame helm
tame helm
short atlas
#

evt_1OHqnaDFt6iTMCHHKcyLLTU8

#

We are experimenting with using application fees instead of destination charges. This may be a better fit for us.

tame helm
#

What type of Connected Accounts are you working with?

short atlas
#

Custom (is that what you're asking?)

tame helm
#

Yep. So you really don't want to use Direct Charges with Application Fees here

#

That is designed for Standard Connected Accounts

#

But will lead to a lot of issues if using with Express or Custom.

#

That said, for the Event you provided above, it did occur on your platform, which is why there is no accountId in the Event

short atlas
#

Well...I'm glad you brought this up because this has been an issue as we do our build out.

When a refund occurs (or chargeback or ACH return), we want the connected account to be responsible for all fees including whatever the platform took out. It appears that flow works better if we use application fees instead of destination charges (correct me if I'm wrong). I did read the link on destination charges and application fees.

tame helm
#

Yeah for that specific case it is true -- if you want to pass on all the fees to your Connected Accounts, in the case of refunds/disputes, then using Direct charges will be easier. However, your platform is still ultimately liable here -- so if the Connected Account is negative then your platform will still be held accountable. Overall the issue with this flow is that it leads to a lot of headaches like:

  • Really hard to address disputes via the Dashboard
  • You have to cover negative balances on Connected Accounts (mentioned above)
  • You lose out on control of fraud via Radar (can't use your platform rules and can't set rules on Connected Accounts
  • Hard to do effective Reporting
  • Customization is limited overall
#

And more

#

Really don't recommend this

short atlas
#

So you recommend using the transferdata when running a payment intent, for example. Doing that from the platform on behalf of the connected account and transferring those funds to the connected account?

Doesn't that also mean that in the event of a dispute, I have to do a reverse transfer of funds from the connected account to the platform whereas I wouldn't have to using an application fee?

I'm just trying to wrap my head around all of the differences as we move from one implementation option to another.

tame helm
#

Yep you got it

#

What you want to do really is wait until the outcome of the dispute is known

#

Then you either reverse the transfer if the dispute is lost

#

Or you just leave it if it is won

#

(Since a won dispute will return the funds to your account)

short atlas
#

Ok. Thank you for the explanation. Let me get this to marinate. I might have some follow ups.

#

One thing I struggle with on destination charges is refunds. If we have a scenario where the platform is charging $2 on a $102 transaction and the account issues a refund (full or partial), Stripe will take a proportional amount from the account and from the platform. It seems like there isn't a way to make the account cover the fees with destination charges. Same with ACH returns. Is there a way to handle this with that approach?

tame helm
short atlas
#

Ah. So execute the refund with reverse transfer as false which queues up funds to send to the payer. Then execute a second call immediately to pull funds from the connected account to the platform?

tame helm
#

Yep

short atlas
#

Ok. That makes sense, but what about automatic debits like a charge.failed (ACH return)? Stripe wants to debit for that factoring in the destination charge ($100 instead of $102 in this case).

tame helm
#

I'm not sure I totally understand what you mean by that. Can you clarify?

short atlas
#

Let's say I run an ACH for $102 and then a charge failed occurs. I later get a payout.created event that includes the payment for 102 a reversal attached to it with a net settlement amount of $100. I take that to mean that the account will be debited $100 while the platform is debited $2. If the platform wanted to still have the account pay those $2, I think we would have to execute a separate reverse transfer.

#

We can take that same scenario to a Visa transaction for $102 that now has a dispute. If the dispute comes in, would the account only be debited $100 while the platform is responsible for the rest?

tame helm
tame helm