In June, a marketplace founder in the Netherlands emailed me. He'd asked an AI about a Stripe Connect problem that was bugging him, and it pointed him to me - apparently I was the only person who had written about it.
The problem he meant is one every marketplace founder hits sooner or later: to pay your sellers on your marketplace, they have to complete Stripe onboarding. Identity documents, bank details, address, business questions. And the standard way to do it is to put that wall right at signup - before the seller has listed anything, sold anything, or earned a cent.
Dont do that! 🛑
Think about the incentives for a second.
You're asking for maximum effort and maximum trust at the exact moment the new marketplace seller has minimum motivation. They just found your marketplace ten minutes ago. They're curious, not committed. And your first move is a government-ID request.
Sellers churn right there. Not because they object to verification - because the order is wrong.
The pattern: defer it
The fix is what I call deferred onboarding, and I've been running it (and writing about it) for years:
When a seller signs up, create a minimal Stripe account for them. Ask for one thing: their country and email.
Let them list and start selling immediately.
When sales happen, their share accumulates - held in the platform's Stripe balance, custodied by Stripe, attributed to the seller in your ledger.
Then later, ask them to complete full onboarding. Their money is sitting there, waiting for them.
The incentive flips completely. Before a sale, Stripe onboarding is a wall between the seller and trying your marketplace. After a sale, it's a wall between the seller and their money. Nobody abandons that form.
The same verification, two different moments. Full six-step flow in the technical writeup below.
I've open-sourced a full implementation if you want the code: stripe-connect-deferred-onboarding-example-repo
The part everyone skips: prefill
Deferred onboarding fixes WHEN sellers verify. Prefilling fixes how long it takes when they finally do - and this was the Dutch founder's plan too: make the final onboarding feel like a confirmation step, not a questionnaire.
The principle: every field you pass into the Stripe account when you create it is a question Stripe never asks the seller. By onboarding time you already know a lot: their name, their email, their country, and the fact that they sell on your marketplace. So pass it all:
Name and email - captured at signup
Country - the one thing you asked upfront
Entity type - individual, so Stripe skips "are you a business?"
Website - your marketplace's storefront URL. That's where they sell, so it's the honest answer, and it kills the "your website" question
Product description - "Products and services sold via [your marketplace]"
Industry code - a generic merchant category, one more question gone
Illustrative - but this is what prefilling does. Seven questions already answered before the seller arrives.
What's left is the only part you genuinely can't do for them: their ID and their bank account. A seller with money waiting, facing a two-item form. That's the whole trick.
(One caveat if you're building this yourself: a few EU countries - France is one - don't let platforms pass identity data server-side at all; it has to travel through a client-side token. The pattern still works, the plumbing just differs a bit.)
The honest part: the EU legal nuance
Here's what that Dutch founder pushed me on, and he was right to.
Under PSD2, you're exempt from being regulated as a payment institution only if you never come into possession OR control of user funds. During the deferred window, the money is custodied by Stripe - a licensed e-money institution - in your platform balance. It never touches a bank account you control, and it can only move on Stripe's rails. That answers the possession question. But "control"? You decide when funds move and where. A regulator could read that either way, and it's jurisdiction-specific.
He asked Stripe directly. Their answer, paraphrased: the model is supported, Stripe holds the funds... and please consult a lawyer for your specific obligations. Which tells you exactly where the line is: the pattern is standard, and the edge is yours to verify.
If you run an EU/EEA marketplace and use this pattern: keep the hold window short, require onboarding before any payout, never sweep held funds into your operating account, and if you're at scale, spend the money on an hour with payments counsel. Don't assume the exemption - confirm it.
I keep the full technical writeup current here, including the six-step flow, the v2 API differences, and this exact PSD2 section: Stripe for Marketplaces: Everything You Need to Know
Go deeper
The full Stripe Connect explainer (why marketplace payments are hard, account types, money flows): Stripe for Marketplaces (2026)
Live 10-minute code walkthrough of the deferred pattern: I Set Up Stripe Connect in 10 Minutes
Stripe's new Accounts v2 API - should you migrate: Stripe Accounts v2 for Marketplaces
And if you'd rather not build any of this: it's what I do all day at Prometora - deferred onboarding, prefilling, and the payout plumbing come built in.
- Rasmus
P.S. This is issue #2 of The Marketplace Guy. I build Prometora, a marketplace platform, and this is where I write down what running the infrastructure under many marketplaces teaches me. If someone forwarded you this: you can subscribe at themarketplaceguy.beehiiv.com.