#halbert-connect-fundsflows
1 messages · Page 1 of 1 (latest)
Hello 👋
What do you mean by the "billing configuration"?
I was trying to create a customer portal for a connect account and received the following error response:
You can't create a portal session in test mode until you save your customer portal settings in test mode at
I was able to get the API call to work when going to the connect account owner's settings and manually updating the customer portal settings. However, I want this to be set up by default. Does that make sense?
Yes, unfortunately you cannot "inherit" this. However, this really begs a larger question. How are you creating payments on the Express account? We do not recommend Direct Charges on Express accounts. In all our recommended integrations the Customers (and therfore the Customer Portals) would exist only on the Platform
This is interesting. Can you explain why you do not recommend direct charges on Express accounts?
We've chosen this method for accounting simplicity
Vs. charging everything to the platform account and then transferring to the connect account
Direct charges mean the Express account is the one responsible for the payment and all things related to it (such as disputes). However, they have limited access to the Stripe Dashboard and therefore cannot perform all the necessary actions to handle situations like disputes.
They are not full Stripe accounts
Also reporting is much more difficult because you need to pull transactions for each Express account to get insights into your financials
So if there is a disput on a charge made to the connect account, the connect account owner cannot contest the dispute?
If they are an Express account, no
If they are Standard, then yes
because they have full access to the Stripe Dashboard
Can we contest the dispute on their behalf?
You can but you have to manually check each account
Also you as the platform are still responsible for negative balances on the Express accounts and this can make refunds much more difficult since the funds aren't starting in your balance
And you cannot use Radar if you want fraud protection
Generally it's just a bad idea
Understood
Another reason we chose to charge directly to the express is because we are holding security deposits, and thought it would be cleaner to hold them in a specific account
Do you agree?
We recommend either Destination Charges https://stripe.com/docs/connect/destination-charges or separate charges & transfers https://stripe.com/docs/connect/separate-charges-and-transfers
I don't see that as cleaner, no.
Okay that is good to know
So with destination charges, if we are charging a customer $1,000 and specify an application fee of $100, the connect account gets the balance?
I.e. the account account gets $900?
Correct
We have a fairly detailed graph of this funds flow here: https://stripe.com/docs/connect/destination-charges#flow-of-funds-app-fee
Alternativelly you could use the tgransfer_data.amount to specify the amount you want to pass to the Express account. That would follow this funds flow: https://stripe.com/docs/connect/destination-charges#flow-of-funds-amount
Can you help me understand this chart? So we want to charge a user $10
Stripe takes a $0.59 fee
Platform is supposed to get a $1.23 fee
I guess the confusion is who bears responsibiltiy for the stripe fee? Does the platform receive the $1.23 - $0.59 = $0.64, or does the connected account receive $10 - $1.23 - $0.59 = $8.18?
Just trying to figure out the net each party receives
The platfrom is responsible for the stripe fees
Then, Stripe fees (0.59 USD) are subtracted from the application_fee_amount and the remaining funds (0.64 USD) are added to your platform account’s balance.
Understood
Okay that makes sense
And how is the following proposal different?
Alternativelly you could use the tgransfer_data.amount to specify the amount you want to pass to the Express account. That would follow this funds flow: https://stripe.com/docs/connect/destination-charges#flow-of-funds-amount
Effectively you specify the transfer amount instead of the application fee?
Correct
So effectively another way of saying the same thing
The paragraphs above each diagram explain how each of them work and how they differ
In the second case the funds are retained by your platform rather than going to the connected account and coming back
In the first example, we say the platform gets $1.23 (minus stripe fee) and the connect account gets the remainder.
In the second example, we say the connect account gets $8.77 and the platform account gets the remainder minus the Stripe fee
In other words, in first example the API input is the $10 + $1.23 application fee, and in the second the input is $10 + $8.77 transfer_data.amount
The customer is charged $10 in each situation. These are just different ways to achieve something similar that work slightly differently and apply to different use cases
got it
It helps to think of this as how it applies to your platform and connected accounts
The application_fee_amount is your Platform taking a fee from the Connected Account in return for some service (for example: providing a web UI that gets them payments). The transfer_data.amount is the same approach but there are minor differences that we call out in the doc.
When using an application_fee_amount, know that:
- The amount collected as an application fee is capped at the total transaction amount.
- The application_fee_amount is always processed in the same currency as the transaction.
- Your platform pays the Stripe fee after the application_fee_amount is transferred to your account.
- No additional Stripe fees are applied to the amount.
When using transfer_data[amount], know that:
- The amount is capped at the total transaction amount.
- The amount is always processed in the same currency as the transaction.
- Your platform separately pays the Stripe fees on the charge.
- No additional Stripe fees are applied to the amount.
- To calculate fees after a payment is created (often for reporting purposes), you need to retrieve the PaymentIntent and subtract the transfer_data[amount] from the amount on the PaymentIntent.