#kmbro-connect
1 messages · Page 1 of 1 (latest)
I need my connected account to cover the refund completely, I don't want to lose any money in my connected account because a connected account starts to refund money.
did you mean "platform" instead of the first 'connected account' in that sentence?
Sorry, I meant -- the connected accounts need to cover the fee, not my platform account
I don't actually have direct customers. All the customers in my account belong to an Express Connected Account.
So if I charge a customer for a $100 invoice, I set an application fee of 3.5%
So the balance transferred into the connected account is just $96.50.
If the connected account then refunds that invoice, I need to not lose any money. the full $100 should be refunded from the connected account balance
ok! well first it depends if you're using Direct or Destination charges. It's not clear to me from your description which you use. Do you have any example Charge/Invoice ID I can check to see which it is?
overall you probably want to look at https://stripe.com/docs/api/refunds/create#create_refund-refund_application_fee which is how you give the application fee your platform took back to the connected account , so it has more money with which to fund the refund. Not sure how that's done on CreditNotes instead of raw Refunds off the top of my head unfortunately
Is it better to use "refunds" directly rather than a creditNote? The documentation for invoices makes it seem like credit notes are preferable when using invoices. Granted I read that documentation and wrote that code 2 years ago, so things could have changed.
I never actually use payments/payment intents/charges directly. I only ever use invoices and finalize them.
credit notes are probably better I would say. But maybe they don't support Connect use cases properly(looking)
Do you have any example Charge/Invoice ID I can check to see how you integrate?
ok unfortuantely I looked and I think we didn't add support for refund_application_fee to the CreditNotes API, which is going to complicate any answer I give here
thanks ok, so this is Destination style, you use transfer_data
you also don't take explicitly an application fee, you set things up to transfer less than the amount so that the difference is the fee(i.e. https://stripe.com/docs/connect/destination-charges#transfer-amount )
so refunds work like this: (typing)
Ah yes. sorry -- That is the current way I do things. I am migrating to use application fees now.
I'll send a better example from the dev environment (it isn't in production yet)
Invoice is $100, transfer $95, Stripe fee is $3.
- on invoice payment — your platform makes $5-$3 = $2 NET ; connected account makes $95 NET
- refund, the default flow would be like this :
-- your platform balance goes -$100
-- you can use https://stripe.com/docs/api/transfer_reversals/create to pull the $95 from the connected account if you wish
-- so overall either your platform NETs -$100 + $2 = -$98 ; connected account NETs $95, or if you reverse the transfer then : platform NETs -$100 + $2 + $95 = -$3 ; connected account NETs $0
ok no worries
ok got it. Then it's mostly the same.
Invoice is $100, your application fee is 5%, Stripe fee is $3.
- on invoice payment — your platform makes 5%, so $5-$3 = $2 NET ; connected account makes $95 NET ($100 transfer - $5 application fee)
- refund, the default flow would be like this :
-- your platform balance goes -$100
-- you can use https://stripe.com/docs/api/transfer_reversals/create to pull the $100 from the connected account if you wish to help you as the platform cover the cost of the refund
-- you can use https://stripe.com/docs/api/fee_refunds/create to send $5 back to the connected account(but you pretty much never do this when using Destination charges as it doesn't make sense, your platform needs that money)
-- so overall either your platform NETs -$100 + $2 = -$98 ; connected account NETs $95, or if you reverse the transfer then : platform NETs -$100 + $2 + $100 = $2 ; connected account nets -$5
Ok great. that is very clear. Thanks!
sorry, updated the maths
Looks like I'll just need to debit the connected account for the remaining balance
I got the gist
you can see in https://stripe.com/docs/connect/destination-charges#flow-of-funds-app-fee that the connected account gets a transfer of the full amount. So if you reverse the transfer during the refund process, you're pulling that full amount back
Ohhh I see
That is what I was looking for PERFECT
That is what I want to happen, so I don't have to debit the connected account after the refund (which is what I am currently doing with the transfer_destination/transfer_amount -- which is why I am trying to switch to application fee in the first place!)
Can I ask a followup question to this?
I want the application fee to be dynamic -- based on the payment method type.
I was going to do this in the invoice created webhook -- meaning -- when a subscription invoice gets created, try to determine the payment method that will be used to pay for the invoice. This works fine unless the initial payment method fails, or somehow an invoice gets left in an OPEN state. Once it is in an OPEN state I cannot update the application fee.
Here is an example:
A customer has an ACH payment method which is the default, and a Credit Card on file as well.
- a subscription is created for $100 on that customer with no payment method information (so it will use the default payment method).
- The invoice for the subscription is created with a 1.5% application fee (I set that bc that is my platform ACH processing fee), and after the webhooks fire, a payment is attempted using the default ACH payment method.
- Tha ACH payment fails for any number of reasons
- A user in my app goes in and sees the payment failed for the $100 subscription. They see there is a different payment method, and attempt to use that CC payment method to pay for the charge.
- Now the CC is used, which stripe charges 2.9% + $0.30 for, but I am only able to collect 1.5% bc I cannot update the application fee on an invoice that has been finalized.
Do you have any creative way of making the application fee dynamic based on what payment method is ACTUALLY used to pay an invoice, not just my "best guess" as described above (and has serious flaws)?
let me think but overall I don't think that's possible
yeah there's no way to do this, everything is set when the Invoice is finalised. It's a common enough pain point. Overall I'd suggest setting your application fee as a more general business-level 'what I need to make profit' . If needed you might try to "true up" the connected account by sending them a small one-off transfer periodically for the differences between taken fees and actual method used by the end-customer. Overall this is not a use case we have good support for.
Ok great. That is what I thought, but I wanted to make sure. Thank you for all your help!