The first time you take a cut of someone else's money, you make a decision about custody. Most people make it without knowing they made it. You do the obvious thing — the whole payment lands in your account, it settles, you take your piece, and you send the rest along a few days later. It works. The books balance. And somewhere in there, without ever choosing to, you've turned yourself into a place where other people's money sits.
Stop on that one. The second those funds land in your account, you're holding them, and now you've got reconciliation you didn't ask for, payout timing that's suddenly your problem, and depending on your volume and where you operate, a money-transmission conversation you really don't want to be in. You've also changed what you are to the business you're serving. Their revenue's parked in your balance, and "you'll get it Tuesday" is carrying a lot more weight than you meant to put on it.
There's a better way, and it starts from a different gut instinct: touch the money as little as you physically can. On Stripe Connect that's a destination charge with an application fee. One charge hits the customer's card. The moment it's captured, your fee comes off the top as the application fee and everything else settles straight into the other party's connected account. Your balance never holds a cent of theirs. There's no second transfer to schedule, reconcile, or watch break — the split's baked into the charge itself.
// One charge. Your fee comes off at capture; the rest settles
// straight to the other party. Your balance never holds their money.
const paymentIntent = await stripe.paymentIntents.create(
{
amount: totalCents, // what the guest pays
currency: 'usd',
application_fee_amount: platformFeeCents, // your cut, taken at the split
transfer_data: { destination: connectedAccountId }, // their money, their account
},
{ idempotencyKey: charge:${reservationId} } // safe to retry by design
);
Two things come out of that, and they both matter more than the code does. First, where you stand legally: if the other party's money never rests with you, you're not sitting where money transmitters sit. Second — and people underrate this one badly — trust. The business you serve watches their money land in their own account. They watch you take exactly what you said you'd take. No float, no "it's processing," no spread they can't see. When somebody's handing you a slice of their revenue, nothing sells like watching you hold none of it.
The easy part's the 80% that goes right. The real work's in the parts most people skip.
Take the processing fee. Every card charge costs you something in interchange and processor fees, and the lazy move is to guess — call it 2.9% and thirty cents — then either eat the difference or bury a little margin in the guess. Don't guess. Charge against the estimate, then true it up to the exact fee the processor hands you on the balance-transaction webhook, so the other party pays the real cost and you take exactly your number. When they pull their statement, your math matches theirs to the penny. You can't fake that after the fact, and that's the whole point.
Idempotency's the next one everybody says they do and almost nobody does right. Key the charge on the transaction instead of the HTTP call, and a retry or a double-click or a dropped connection can't ever mint a second charge. The key comes off the reservation, so repeating the call is safe by design, not by luck.
Then there's what you're willing to believe. The client telling you it worked isn't the truth — it can stall, drop, or flat out lie. The processor's signed webhook is the truth. Capture, the fee true-up, every write downstream, all of it hangs off that webhook, so what your system thinks happened and what actually happened to the money can't drift apart. And the whole rail fails closed. If the other party hasn't finished payout onboarding, it won't charge at all. Turning down money you can't route yet beats taking it and owing it.
Last thing, the future. Get a card authorized once, then charge it weeks later for the next go-round — off-session, against the saved method, with the authentication handled so it doesn't quietly die on an SCA check. That's the whole difference between a card on file that works and one that blows up on the exact day you needed it.
All of this is the patient, unglamorous version of something most platforms do in a hurry, and the gap between those two is where you either earn trust or lose it. I build payment rails for hotels — the plumbing that moves a guest's money to the property and a small fee to us — and the entire thing sits on one rule: the property's money is theirs, every second of the way, and we're visibly holding none of it. In payments, whoever touches the least gets trusted the most. The move was never a smarter way to hold the money. It's building yourself out of the custody business for good.
