#nameless-connect
vast cradle
I was interested in potential logic flaws with the proposed solution above, after "Instead we do the following", other than the mentioned Connect Fees no longer showing any fees (since they're not application_fee defined
or if there's a better way to solve multi-transfer payments while still allowing non-reversal of application fee
An example flow would be this
which should allow a refund to be processed as
inner hill
gimme a second to look through the diagrams
vast cradle
no problem :)
inner hill
is pepperuk - your platform account?
vast cradle
Yes, I should have noted that haha! In the example, we're in "franchise yes" mode, otherwise the £1 from the franchiser1 would instead go to merchant1
inner hill
merchant1 and franchiser1 are two different connected accounts?
vast cradle
yes, both under our platform account
inner hill
hmmm, alright, i would have drawn the diagram slightly differently cause the PaymentIntent is created on your platform account
vast cradle
Indeed, everything is created on the platform account, except the one place it's noted as from the merchant1 account, in which we pass { stripeAccount: acct_merchant1 } into the SDK transfers.create
inner hill
i think the new way you've designed it is fine as it is. What you would be doing is what we call a Separate Charge and Transfer (SCT) fund flow [0] - this is the flow we recommend if you need to split funds to multiple connected accounts from a single payment.
But you mentioned that previously you've ran into a few problems with your original solution e.g. with wanting to not refund application fee, or partial refunds not partially reversing transfers - can you elaborate more on these?
vast cradle
Essentially if we supply amount in the transfer_data on payment intent creation, when refunding the payment intent, setting refund_application_fee to false is ignored and still refunds, which is not acceptable for our platform since we're still charged fees for IC++, Interchange, 3DS2 etc
other than that, just a bunch of non propagation of description and metadata from Payment Intent to Charge / Transfer
so we end up listening to a load of webhooks anyway to update metadata on the fly so it shows up in reports
inner hill
ah, that's understandable. So to clarify, your current method (i.e. using transfer_data) is what we call destination charges : https://stripe.com/docs/connect/destination-charges
vast cradle
yup, we use that for our "non franchise" setups
and it works wonders (other than the manual metadata updates etc. but security concerns make sense there)
inner hill
to explain a bit more, refund_application_fee would work in the way you expect if you used application_fee instead of transfer_data[amount]
i.e. it wouldn't refund the application fee unless you set refund_application_fee=true
vast cradle
the only reason we use transfer_data amount is due to not wanting to send it all to the merchant, but a portion also to the franchiser, plus take application fee - so lets say we have a £10 amount, minus a £1 app fee and minus £1 franchise fee.
In this situation we use transfer_data[amount]: £8, application_fee of £1, and create a transfer of £1 to the franchiser
but this then refunds application fee even if set to false
inner hill
yes, because refund_application_fee only works on the application_fee amount. It doesn't consider transfer_data[amount] as an application fee
vast cradle
of course - but the platform account still loses £10, and gets £8 back from the merchant account - we manually reverse the franchise transfer for £1, but we still lose out on the £1 app fee
while the transaction is at "0 loss" overall, the platform is at a loss because it's still charged the fees for 3ds2, interchange etc
inner hill
the way I would do it on your current flow would be :
PaymentIntent is created with £10 with application_fee : £1 (transfer_data[destination]=merchant1), create a separate transfer for £1 to franchiser
vast cradle
okay! I'll keep that in mind and revise the flows - I'll send an email over for TSE's at some point with some more data that's actually tracable on their end just to confirm it's not a bug we're seeing or anything - thanks for the help!
inner hill
i do want to mention, there's nothing wrong with switching to Separate Charges and Transfers also
vast cradle
of course it's much easier if there's a Stripe handled way of doing it through :P