Escrow on Stripe Connect: the three places the money can sit

If your marketplace sells anything that happens later, a session, a rental, a shipped parcel, you have a timing problem with the money. The buyer pays today. The seller should get paid when the thing actually happens. And the default way of wiring up Stripe Connect pays the seller at the exact second the card is charged.

That's fine for a t-shirt. It's a problem for a booking that hasn't happened yet, because if the provider no-shows tomorrow you're clawing money back from a balance that may already have paid out to their bank.

On August 25, 2026 I published a video and a small open-source repo on how to build the escrow version. This issue is the part that doesn't fit in a code walkthrough is where the seller's share can sit while you wait, what each choice costs you, and the two things I only learned by running it.

A buyer pays 100. You take 20. The question is where the other 80 lives until the job is done. There are exactly three answers.

1. In the seller's balance, behind a timer. One setting when you create the connected account then a payout delay of, say, seven days. Stripe moves the 80 to the seller immediately, but holds it in their Stripe balance before it reaches their bank. Zero code after that.

The catch is that it's a timer, not a condition. If the session is cancelled on day two, the money is still in the seller's balance and you're doing a refund with a transfer reversal. It works, but you're relying on the seller's balance covering it. Fine when your risk is low and you just want a buffer.

2. In the seller's balance, and you trigger the payout. Same destination charge, but the seller's payout schedule is set to manual. The 80 sits in their balance, labelled as theirs, and nothing moves to their bank until your platform says so.

This is the option almost nobody talks about and the one I'd pick for most booking marketplaces. The money is already in the seller's name, refunds reverse cleanly, and you control the timing. It's the least code of the three.

3. In your platform's balance. The buyer pays your account, with no destination. The full 100 lands with you. When the job is done, you create a transfer of 80 to the seller. Until then, a refund is just a refund: no reversal, no seller involved, no negative balances.

This is real escrow. You decide the condition and the timing, and the seller only ever sees money you've released.

With option 3 there are two kinds of refund, and which one you get depends on one thing - have you paid the seller yet?

Before release, a refund is one call on the original payment. The seller was never involved. This is the case you're designing for.

After release, it's two calls. You reverse the transfer, then refund the charge. If the seller has already paid out to their bank, Stripe takes it from their next transfers, and in some countries the reversal just fails.

So your hold window isn't a technical setting. It's your refund policy. The comment that started all this asked for "provider gets paid 24 hours after the session". That's not a random number. It's saying: the buyer has one day to complain before the refund gets expensive. Pick your window by asking how long a buyer needs to notice something went wrong, not by what feels generous to sellers.

I tested the repo end to end, against a Stripe sandbox, and two things failed that no tutorial had warned me about.

The transfer currency has to match your settlement currency. My platform account settles in euros. I charged the test buyer in dollars, and the transfer to the seller failed: the charge had landed in my balance as EUR, so a USD transfer tied to it wasn't allowed. If your platform is in Europe, charge in euros and give your sellers euro accounts. If it's in the US, dollars all the way through. Mixing them silently breaks the release step.

Platform and seller have to be in the same region. Separate charges and transfers work EU to EU or US to US. An EU platform can't hold funds and transfer to a US seller this way at all. Check Stripe's current docs for your specific countries before you build on this; this is one of the things they change.

Both of these will show up as a failed transfer on the day you release, which is the worst possible day to find them.

Someone left that comment on an earlier video, and it deserves a straight answer rather than a wave.

The money is not in your bank account. It's in your Stripe balance, and Stripe is the licensed institution holding it. That settles possession. What it doesn't settle is control: whether your platform, by deciding when the seller gets paid, is exercising enough control over client funds to need its own authorisation or to fall under an exemption. That's arguable, it differs between the EU, the UK and the US, and it depends on how much you're holding and for how long.

I'm not a lawyer. If you're going to hold meaningful amounts, ask one before launch, not after. And don't park funds for months; Stripe expects you to transfer within a reasonable window. If that makes you nervous, choose option 2 again where the money sits in the seller's name the whole time.

If you sell things that happen later:

Video: https://youtu.be/dw-y9XuKJaw
Repo: https://github.com/razz1000/stripe-connect-escrow-example-repo
The neutral guide, with the holding-funds FAQ: https://www.prometora.com/learn/stripe-for-marketplaces