Choosing a Stripe Connect funds flow
Most teams pick a Stripe Connect charge type the way they pick a database in week one. Whatever the first tutorial used. Then six months in, a refund crosses a payout boundary, a connected account goes negative, and they realize the charge type was an architectural decision the whole ledger now depends on.
Here is the version I wish someone had handed me before I built a B2B2C platform on Connect.
The three options, in one breath
Destination charges. You create the charge on the platform account and name a connected account as the destination. Stripe moves the money and takes your application fee automatically. Simplest to start.
Separate charges and transfers. You charge on the platform, then create one or more transfers to connected accounts later, as separate API calls. Most flexible, most rope.
Direct charges. The charge is created on the connected account itself. The connected account is the merchant of record. Cleanest for a true marketplace where the seller owns the customer relationship.
That summary is on every comparison page. The part that actually bites you is what each one commits you to after the happy path.
What actually bites you
Who owns the negative balance
When a refund or dispute lands after the money has already been paid out, some account goes negative. With destination charges, that is more likely to land on your platform balance. With direct charges, it lands on the connected account, which is correct in principle, but now you need a real answer for “the seller’s balance is negative and they have stopped responding.”
If you have not decided, on paper, who eats a negative balance in every failure mode, you have not finished choosing a funds flow.
Refunds and the fee you already took
Refunding a destination charge does not automatically claw back the application fee unless you say so. Reversing a transfer is a separate operation from refunding the customer. It is entirely possible to refund a buyer in full while the connected account keeps money it should have given back. That is a quiet, compounding ledger drift that nobody notices until reconciliation.
Reconciliation surface area
Separate charges and transfers gives you beautiful flexibility. Split one payment across three parties, hold funds, release later. It also means your ledger now has to track charges and transfers as independent objects that you are responsible for keeping consistent. Every bit of flexibility you buy here is a bit of reconciliation you now owe.
How I actually choose
A rough heuristic that has held up:
One platform, simple split, you are the merchant of record. Destination charges with an application fee. Do not reach for more.
Funds need to be held, split many ways, or released on a delay. Separate charges and transfers, and budget real engineering time for the ledger.
True marketplace, sellers own their customers and their own risk. Direct charges on connected accounts, and invest early in negative balance handling.
The trap is picking the flexible option “to be safe.” Separate charges and transfers feels like the senior choice, but if you do not need to hold or split funds, you have just signed up to hand maintain consistency you could have gotten for free.
The one thing to write down first
Before any code, draw the funds flow for the unhappy path. A buyer pays, the money is split and paid out, and then they dispute. Trace exactly which balance goes negative, what your fee does, and who you bill to make the ledger whole again. If that diagram is clear, the charge type chooses itself. If it is not, no charge type will save you.
That diagram, not the integration, is the actual hard part.
I'm Adam. I architect and rescue Stripe Connect payment platforms. I built a full B2B2C healthcare marketplace on Connect end to end: split payments, payouts, and ledger reconciliation. If you're a founder or eng lead building or fixing one, say hello.