The complete guide to Stripe Connect for marketplace founders
Stripe for Marketplaces: Everything You Need to Know in 2026
Payments will make or break your marketplace. Stripe Connect lets you move money between buyers and sellers - but setting it up is one of the hardest parts of building a marketplace. Here's everything you need to know.
Payments will make or break your marketplace. You can have the perfect niche. You can have buyers. You can even have sellers. But if money can't move cleanly between them - you don't have a business.
And that's where Stripe Connect comes in. It's the payment infrastructure behind marketplaces like Lyft, Instacart, Kickstarter, and most ecommerce marketplaces. But setting it up yourself is one of the most complex parts of building a marketplace.
In this guide, I'll break down everything you need to know - what Stripe Connect is, why it's hard, which account type to choose, how money flows, and the biggest mistakes to avoid. If you're earlier in the journey and not sure where Stripe Connect fits in the bigger picture, start with our guide on how to start an online marketplace first.
Read the full video transcript▼
Why payments make or break your marketplace (0:00)
Payments will make or break your marketplace. You can have demand and you can have supply, but if money doesn't move cleanly between buyers and sellers, you don't really have a business. In this video I'll explain exactly what Stripe Connect is, why it's so hard to implement, which account type you should usually choose, and how marketplace money actually flows. I'll also explain a powerful technique I call deferred onboarding, and then I'll show you how all of this is handled inside Prometora.
Regular Stripe vs Stripe Connect (0:30)
Let's start with the difference between regular Stripe and Stripe Connect. Regular Stripe is one business taking payments - think of a normal e-commerce store. Stripe Connect is a platform taking payments on behalf of other people, which is exactly what you do on a marketplace, and that's why you need it.
In a marketplace you have a platform account, owned by you as the marketplace owner, and a number of connected accounts for all your sellers. Stripe Connect handles KYC (know your customer) and identity verification, compliance, payment splitting, payouts, and tax reporting. Without Stripe Connect, in most parts of the world, you cannot legally move money between your users.
Why Stripe Connect is hard to implement (1:30)
Stripe Connect gives you the building blocks, but it does not build the system for you - you have to set that up yourself, and that can get quite complex. It includes seller onboarding, capabilities, transfers versus destination charges, refund handling, disputes, setting up webhooks, edge cases, and payout timing. That's where a lot of marketplace founders hit a wall.
The three account types (1:54)
Stripe Connect has three account types: Standard, Express, and Custom. They all have advantages and disadvantages, but most marketplaces should probably go for Express because it's the easiest to integrate. With Express, Stripe Connect takes care of all the compliance and you just handle the UX. With Standard, the seller owns the Stripe account. With Custom, you get full control but you also take on the full compliance burden. So if you're just starting out, Express is usually the right choice. I'll share the docs in the description so you can see what each one requires.
How marketplace money flows (2:39)
Here's how the flow works. A buyer comes to your marketplace and buys something, so they're sent to Stripe Checkout and pay - let's say $100 for a product. That $100 includes your platform fee. If you take 10% per transaction, $10 is your commission on that sale. The seller has an Express Stripe account and receives the money minus your platform fee and minus the Stripe fees. That lands in their Express Stripe account, and they can later transfer it to their own bank account.
The retention killer: onboarding too early (3:24)
There's one real retention killer to be aware of. Stripe onboarding requires sellers to complete a 5-10 minute compliance form before they can sell anything. That's a retention killer because most of your sellers will drop off - they haven't made any money on your marketplace yet, so it's too early to send them through onboarding, and most of them churn.
Deferred onboarding: how it works (3:47)
That's why I always do something I call deferred onboarding. I've open-sourced my project on GitHub - the link is in the description. The idea is to create a minimal Stripe Express account for the seller up front, only requiring the country. Then you let sellers start accepting payments immediately, instead of sending them straight to KYC, because they haven't had any positive experience or earned any money yet. You prompt for full onboarding later, once they've made sales and are invested in your platform.
Walking through the payment flow: a user wants to sell, so we create a minimal Express account asking only for the country, and the account is created with manual payouts. A buyer purchases from the seller, the payment succeeds, but the platform holds the funds and updates the seller's pending earnings - so the seller has earnings pending while the money is held by the platform. Later, once the seller has made three or more sales, we show them the 'complete onboarding' prompt and send them to the KYC form. Now they have a strong incentive to go through that 5-10 minute form, because they want their money. The seller completes onboarding, the account is verified, we transfer all pending earnings to them, and future payments go directly to the seller instead of the platform.
Risks to be aware of (6:05)
There are some things to be aware of with this approach. Because you hold the funds initially, you as the platform owner carry the risk. It's all covered in the repository, but you'll want to set up volume caps and sales thresholds, and be aware that there can be transfer delays after onboarding. Setting up this kind of risk-based logic is important, and it's all explained in the repo, so go check that one out.
How Prometora handles it (6:38)
On Prometora, my marketplace builder, everything we just talked about - Stripe Connect and the deferred onboarding approach - is handled for you. If this feels overwhelming and you're considering building your own marketplace, all you do on Prometora is go to Stripe Connect, add your Stripe Connect keys (the publishable key and the secret key), set your commission rate - say 20% on all transactions - save, and you're ready to go. It's a very easy way to get going with your own marketplace using Stripe Connect and deferred onboarding.
Wrap-up (7:34)
That's it for this one. If you're interested in deferred onboarding and want to know more, check the deferred onboarding repo linked in the comments below. And if you're seriously considering building your own marketplace, go check out Prometora. Give the video a like, and if you find marketplace building interesting, consider subscribing to the channel - it would be a big help. Thank you so much, and I'll see you in the next one.
What Stripe Connect Actually Is
First, let's clarify something. Regular Stripe and Stripe Connect are NOT the same thing.
Regular Stripe is for one business taking payments from customers. Stripe Connect is for platforms - applications that move money on behalf of other people.
In a marketplace, you have:
- A platform account - that's you, the marketplace operator
- Multiple connected accounts - those are your sellers
Stripe Connect handles the hard parts:
- Identity verification (KYC) - verifying sellers are who they say they are
- Compliance - handling regulatory requirements across countries
- Payment splitting - automatically dividing payments between you and sellers
- Payouts - sending money to seller bank accounts on schedule
- Tax reporting - generating 1099s and other tax documents
Without Connect, you legally cannot collect payments and distribute them to other people. You'd be acting as an unlicensed money transmitter.
Why Stripe Connect Is So Hard to Set Up
On paper, Stripe Connect sounds simple. In reality - it's one of the hardest parts of building a marketplace.
Here's what you actually have to deal with:
- KYC and onboarding flows - each seller must verify their identity, bank account, and business details
- Country restrictions - Stripe Connect is available to platforms in 40+ countries, but rules vary by region
- Split payments vs. destination charges - two different models for how money is routed, each with trade-offs
- Refund logic - when a buyer requests a refund, who pays? The seller? The platform? Both?
- Dispute handling - chargebacks on marketplace transactions are complex because multiple parties are involved
- Testing payouts - you can't just test with fake money; payout flows need real verification
- Webhooks - Stripe sends events for every state change; you need to handle dozens of them
- Edge cases - what happens when a seller fails verification mid-transaction?
Stripe gives you the tools - but YOU have to build the system around it. The onboarding UI, the payout logic, the error handling, the seller dashboard - that's all on you.
See Prometora pricing or the multi-vendor marketplace builder. The rest of this article still applies if you want to understand Stripe Connect deeply for your own implementation.
The 3 Stripe Connect Account Types
On the original (v1) Connect API, Stripe has three account types - Standard, Express, and Custom - and picking the wrong one can cause serious headaches down the road. The newer Accounts v2 model (covered in the next section) replaces these fixed types with a more flexible setup, but the three types are still the clearest way to understand how Connect works - and they're still fully supported.
1. Standard Accounts
The seller owns and controls their own full Stripe account. Stripe handles everything - onboarding, compliance, dashboard. You have the least control over the experience. The seller sees the Stripe dashboard directly, and branding is Stripe's, not yours.
2. Express Accounts (Recommended for Most Marketplaces)
Stripe handles compliance and verification, but you control the user experience. Sellers go through a Stripe-hosted onboarding flow, but it's lighter than Standard. This is the sweet spot - you get a good balance of control and simplicity without the compliance burden. (Prometora itself ran on Express for most of its life and moved to the Accounts v2 equivalent in May 2026 - more on why below.)
3. Custom Accounts
Full control over everything - onboarding UI, dashboard, communication. But full responsibility too. You're handling compliance, identity verification flows, and regulatory requirements yourself. Massive compliance burden. Only choose this if you have a dedicated engineering and legal team.
The bottom line: if you're building a typical marketplace in 2026, Express is almost always the right starting choice on v1. The Accounts v2 setup that Prometora now runs (dashboard: "none" + embedded components) is the modern equivalent of Express, but with the entire seller experience inside the marketplace site - no Stripe-hosted dashboard at all. See the v2 section below for what that means in practice.
Accounts v2: The New API (December 2025)
In December 2025, Stripe shipped Accounts v2 - a new way to model connected accounts on Connect. The three account types above (Standard / Express / Custom) still exist and aren't going away. But if you're starting a new marketplace in 2026, Stripe now recommends building on Accounts v2 instead of the legacy v1 model.
I migrated Prometora to Accounts v2 in May 2026 and broke down the whole decision in this video - what actually changed, who should migrate, who shouldn't, and the OAuth gap nobody mentions:
Read the full video transcript▼
Why I'm making this video (the Stripe outreach email) (0:00)
A few weeks ago I got an email from Stripe, from their outreach team, asking me to update one of my articles because Stripe had shipped a new Connect API and I hadn't mentioned it. I thought that was interesting, so I went and read all the docs, then the migration guide, and then had a long thought process about whether we should actually migrate Prometora to the new API.
In this video I'll give you my honest version of what I found: what Stripe Accounts API version 2 actually is, who should migrate and who shouldn't, what it costs to do, and the one thing people aren't talking about. So if you're running a marketplace on Stripe Connect, or thinking about building one, this video is for you.
The 3 real changes in v2 (0:48)
Let's look at the new Accounts v2 API: how it works and how it's different from v1. With v2 you define the interactions between your platform, the connected accounts, and Stripe - things like funds flow and loss liabilities. You set the responsibilities, the dashboard access, and the KYC requirements: who is responsible for collecting KYC.
In Accounts v1, which most of you are probably still on, you basically pick a preset: Standard, Express, or Custom. Each preset locks the dashboard, capabilities, and responsibilities together. In v2 it's broken down - you pick dashboard access, configs, responsibilities, and identity, one by one.
Dashboard is what the seller logs into on Stripe's side: the full Stripe Connect dashboard, the stripped-down Express view, or nothing at all, where you embed it on your own marketplace as a white-label solution that doesn't look like Stripe. That last option is the one I've chosen on Prometora, because it's the best one in my opinion. Configs are what the account is allowed to do: merchant means it can accept payments, recipient means it can get paid out, customer means it can be charged. Responsibilities are who owns the money risk - the fees collector takes the platform cut, and the losses collector eats a negative balance. Identity is the KYC data, collected once and reused instead of being recollected every time you add a capability. So in v1 all of these were decided the moment you picked Standard, Express, or Custom. In v2 you set each one independently.
There's another difference. In the old v1 API you must create an Account object for a connected account to accept payments, and a separate Customer object to associate the same business with the payments they make to your platform - two objects you map together, two IDs. In v2 that's combined into one Account object: one ID, no mapping table. It also means identity is stored once. If you've collected information about a user and later make a small change, you don't have to recollect everything - you just add that specific layer on top, and everything you already collected is still there.
The OAuth gap nobody mentions (4:14)
Everything so far about v2 is positive, but there's one thing to be aware of. The docs say that if your platform uses OAuth to authenticate with connected accounts, you should continue using the v1 APIs. So if you let sellers who already have a Stripe Connect account connect using OAuth, that can't be done on v2. They don't say whether this will come later - I don't know - but it's something to be aware of. If you're using OAuth right now, you should not switch to v2, because it's not possible at the moment.
By the way, the docs also say Stripe discourages indefinitely maintaining both Accounts API versions at the same time. So they're basically saying either stay on v1 or go fully on v2, at least as I understand it.
Decision tree: 4 cases, who should migrate (5:22)
So how do you decide whether to stay on v1 or migrate to v2? I made a decision tree. Do you use OAuth? If you do, you'll have to stay on v1, because it isn't supported on v2 and might never be. If you're a brand-new marketplace with no existing accounts, you might as well go straight to v2 - it's the newer API, the one Stripe is focusing on, a cleaner model, and no migration later.
If you're an existing marketplace with connected accounts, it depends on how many. If you have hundreds or thousands, there's no rush - v1 is still fully supported and you can migrate later. And if you're early in your journey and still relatively small, it depends on the v2 features. If you prefer the old Standard/Express/Custom way, you could start on v1 and migrate later, though you'll probably have to migrate at some point anyway, since v1 might not be around in, say, five years. But if you like the v2 way, you might as well migrate now, while the cost is at its minimum and you're still small.
The hidden upside (Embedded Components + v2) (6:54)
If you decide to switch to v2, I'd really encourage you to also look at Stripe's Embedded Components, which they've been investing in a lot recently. They're a way to make everything look like it's happening inside your marketplace, kind of like an Etsy payment experience.
Today, on a normal Stripe Connect marketplace, it often looks like this: a seller signs up on your marketplace, and to onboard they're sent off to Stripe in another tab. All the emails come from [email protected], and they log into their connect.stripe.com account - the typical Express way. So they have two logins, one to your marketplace and one to their Stripe Express account. That's a bit weird, because that's not how it works on big marketplaces like Etsy.
But if you migrate to v2 and add the Embedded Components, you can make your marketplace have everything inside it, so it looks like a full-blown Etsy-style marketplace. Onboarding happens on your marketplace instead of a Stripe link - you click a button, a modal appears, and the seller adds their information right there. You also get inline payouts, inline balance, and inline account management, so there's only one login. Stripe still handles everything in the background, but it looks like it's all handled on your marketplace. That's a much better experience for your sellers, and it makes you look way more professional.
How we're approaching it at Prometora (8:50)
Now let me show you what it looks like on Prometora, because we're now using the v2 API together with Stripe's Embedded Components. Everything happens on your marketplace - you're not sending sellers to some Stripe link.
First you sign up - there's a 14-day free trial. Then you go to the payment area and add your Stripe test keys; you do everything with test keys first, then move to production keys afterwards. Then I go to my live marketplace and sign up as a test seller. In the seller dashboard I can already make a listing, because deferred onboarding is still there - I can list, make my first couple of sales, and onboard afterwards. Sellers have a much higher incentive to onboard once they've made a couple of sales, because then they want their money.
When I onboard as a seller, I click Connect Now, pick my country - I'm from Denmark, so I pick Denmark - and click Connect. Before the Embedded Components, we'd send the seller to a Stripe link; that's not happening anymore. Now a modal pops up that says 'complete your Stripe onboarding.' I click 'add information' and I'm still inside my marketplace. It says Prometora up top, but it'll show whatever you named your Stripe account, usually your company or marketplace name. I add my personal KYC information, and now I'm fully onboarded. On the sidebar there's a new tab called Finance, where I can do everything: pay out money, see my balance, my transactions, and tax documents. Everything is now on your marketplace, which looks way more professional.
So that's how the v2 Accounts API works together with Embedded Components. If you're considering building an online marketplace, check out Prometora - there's a 14-day free trial. Thank you so much, and I'll see you in the next one.
Two things change with v2:
- Flexible configurations replace fixed account types. Instead of locking a connected account to a single type, you attach configurations - merchant (to accept payments), customer (to be charged as a customer), recipient (to receive transfers). An Account can have multiple configurations at once.
- One Account object replaces separate Account + Customer. In v1, if a connected seller also bought something on your platform, you had to create a separate Stripe Customer object and keep a mapping between Account ID and Customer ID. In v2, the same Account object handles both - no more dual-object bookkeeping.
Should you use Accounts v1 or v2?
- New platforms launching in 2026: start on v2. Simpler identity model, fewer objects to track, and it's the path Stripe is investing in.
- Existing platforms on v1: you don't need to migrate today. v1 isn't deprecated. Stripe does discourage maintaining both versions indefinitely, but offers a migration guide when you're ready.
- OAuth-based integrations: stay on v1. v2 doesn't support OAuth-authenticated connected accounts yet.
For the full v2 reference, see Stripe's Accounts v2 documentation. Most of the rest of this article - payout flows, KYC, webhooks, refunds, disputes - applies identically to both v1 and v2. The API surface changed; the underlying marketplace mechanics didn't.
How Money Actually Flows Through a Marketplace
Let's walk through a real example. Say a buyer purchases something for $100 on your marketplace, and your commission is 10%.
- Buyer pays $100 - the full amount goes to Stripe
- Stripe takes its processing fee - approximately $3.20 (2.9% + $0.30)
- Your platform takes its commission - $10 (your 10% application fee)
- Seller receives $86.80 - the remainder after both fees, landing in their connected Stripe account balance
- Stripe holds the funds - in the seller's connected account, based on your payout schedule (usually 2-7 days)
- Seller gets paid - Stripe pays the balance out from their connected account to their bank account
Those fee figures use US card pricing (2.9% + $0.30). Stripe's processing rates vary by country - standard European Economic Area cards, for example, are typically 1.5% + €0.25, so the seller keeps more than in this US example.
This all happens automatically through Stripe Connect - if it's set up correctly. If you don't understand this flow, you can't debug issues when money goes missing or sellers complain about incorrect payouts.
The Seller Onboarding Problem
Here's the real retention killer. Traditional Stripe onboarding requires sellers to complete a 10-15 minute compliance form BEFORE they can sell anything.
Think about that from the seller's perspective. They just signed up for your marketplace. They haven't made any money yet. There's no emotional investment. And now you're asking them to provide their ID, bank details, tax information, and business documents - before they've experienced any value.
Most drop off. They haven't made money yet, so there's no incentive to push through the friction. And your marketplace loses sellers before they ever list a product.
Deferred Onboarding: The Solution to Seller Drop-Off
This is why I use something called deferred onboarding - and I've open-sourced the full implementation on GitHub.
Instead of forcing sellers to complete full Stripe onboarding upfront, the deferred approach works like this:
- Step 1: Create a minimal connected Stripe account - only the seller's country and email are needed to start (an Express account on v1; a minimal Account on v2)
- Step 2: Let them start listing products and accepting payments immediately
- Step 3: The platform holds the seller's share in its Stripe balance, custodied by Stripe on its own rails - an unverified account can't receive transfers yet, so it stays there until the seller verifies
- Step 4: Track pending earnings in your database as sales come in
- Step 5: After a threshold (e.g., 3 sales), prompt the seller to complete full onboarding
- Step 6: Once verified, automatically transfer all accumulated earnings to the seller
It becomes: "You have $240 waiting. Complete onboarding to receive your payout."
Sellers who have pending earnings are dramatically more likely to complete verification. The incentive is real and immediate.
How the Two Payment Modes Work
The deferred onboarding pattern uses two different payment flows depending on the seller's verification status:
For unverified sellers (before full onboarding): The platform creates the charge and holds the funds in its Stripe balance - custodied by Stripe on its own rails, never in a bank account you control. The seller's portion is tracked via metadata (seller_amount) and accumulated in a pendingEarnings field in the database. Unverified connected accounts don't have the transfers capability active yet (it's called transfers on v1 and stripe_balance.stripe_transfers on v2), so Stripe won't allow direct transfers.
For verified sellers (after onboarding): Payments use destination charges with transfer_data.destination pointing to the seller's connected account. Funds flow directly to the seller, and the platform takes its fee via application_fee_amount. This is the standard Stripe Connect flow.
The magic happens in the account.updated webhook. When Stripe reports payouts_enabled: true, the system automatically transfers all pending earnings to the seller's newly verified account.
Production Considerations
Deferred onboarding means your platform holds funds initially - custodied by Stripe in your platform balance, not in a bank account you control. Even so, you carry the dispute risk during the holding period, because the charge sits on your platform account. Before going to production, consider these safeguards:
- Volume caps - limit the number of sales or total dollar amount before requiring onboarding
- Transfer delay - wait 7-14 days after onboarding before transferring funds (covers the dispute window)
- Refund controls - keep refunds platform-controlled until the seller is verified
- Sales threshold - trigger onboarding prompts after a reasonable number of sales (1-3 is a good starting point)
pendingEarnings field), but that's accounting, not a ring-fenced per-seller account.Why this matters: under PSD2, only parties that never come into possession or control of user funds are exempt from being regulated as a payment institution. The deferred window briefly holds and directs seller funds, so the "control" question is arguable. The standard basis marketplaces rely on is that Stripe is the licensed fund-holder and the platform never takes funds into its own account - but how a regulator reads "control" is jurisdiction-specific (e.g. De Nederlandsche Bank in the Netherlands, BaFin in Germany). If you operate in the EU/EEA, keep the hold window short, force onboarding before payout, never sweep the held balance into an operating account, and confirm your position with Stripe and local payments counsel before relying on it. Don't assume the exemption.
v1 vs v2 note: The deferred-onboarding pattern works identically on Stripe Accounts v2. You still create an Account with minimal identity (country and email only), still hold funds until requirements are satisfied, and still trigger payout-release on a state-change webhook. The capability names change (the v1 transfers capability becomes stripe_balance.stripe_transfers, v1 payouts becomes stripe_balance.payouts), and the webhook surface differs slightly, but the six-step flow above is preserved. If you're starting on v2, replace the v1 capability and webhook references with their v2 equivalents and the rest of this section still applies.
The open-source repo demonstrates the full pattern with code examples - but production requires these additional safeguards based on your specific risk tolerance.
Prefill Everything You Already Know
Deferred onboarding solves when a seller verifies. Prefilling solves how long it takes when they do. By the time a seller is ready to onboard, you already know a lot about them - their name, their email, their country, and the fact that they sell on your marketplace. Every field you pass into the connected account when you create it is a field Stripe won't ask the seller again, because Stripe skips questions that are already answered. So the form shrinks down to the only things you genuinely can't fill in for them: their identity documents and their bank account.
When you create the connected account, prefill everything you can. In Prometora, that's:
- Name - captured at signup, passed straight into the account's individual identity
- Email - set as both the account's contact email and the individual's email
- Country - the one thing you ask for upfront, reused for both the account and the address
- Entity type - set to
individual, so Stripe skips the "are you a business or an individual" question - Website - prefilled with your marketplace storefront URL. The seller genuinely sells on your marketplace, so it's the honest answer - and it skips Stripe's "Your website" question (the statement descriptor derives from it too)
- Product description - a short "Products and services sold via [your marketplace]" line, so Stripe doesn't ask what they sell
- Industry (MCC) - a generic merchant category code, so the "what kind of business is this" question is answered as well
The payoff: a seller who has already earned money on your marketplace clicks "complete onboarding" and only has to provide their ID and bank details. Everything else is filled in. Combined with deferred onboarding, you've removed both reasons sellers drop off - they only onboard once they're motivated by pending earnings, and the form they finally hit is as short as Stripe allows.
How Prometora Handles All of This
Inside Prometora, all of the Stripe Connect complexity - including deferred onboarding - is abstracted away. Here's what that means in practice:
- Stripe Connect is pre-configured - sellers are created on Accounts v2 (
dashboard: 'none'+ embedded components), no API integration needed - Deferred onboarding is built-in - sellers can list and sell before completing Stripe verification, with pending earnings tracked automatically
- Automatic payout on verification - when a seller completes onboarding, all accumulated earnings are transferred immediately
- Commission logic is handled - set your percentage and it's automatically collected on every transaction
- Webhooks are already wired - account updates, payout events, dispute notifications, and verification state changes are all handled
- Shipping payout deferral - for physical goods, payouts are held until the seller marks the order as shipped
- Seller retention is optimized - the entire flow is designed to minimize drop-off and maximize completed onboarding
You don't write a single line of payment code. You don't read Stripe API docs (unless you want to!). You don't build webhook handlers. You connect your Stripe account, set your commission, and your marketplace handles payments - including deferred onboarding - from day one.
Comparing platforms? See the full marketplace software comparison, or specifically Prometora vs Sharetribe side by side.
Common Mistakes to Avoid
After building multiple marketplaces and helping others launch theirs, these are the biggest Stripe Connect mistakes I see:
- Choosing Custom accounts too early - you don't need full control on day one. Start with Express, or the equivalent minimal Accounts v2 setup.
- Not testing payouts - test the full flow: buyer pays → seller receives. Don't assume it works.
- Ignoring refund logic - decide upfront who absorbs the cost of a refund. Document it clearly.
- Not handling disputes - chargebacks happen. Have a process before they do.
- Forcing full onboarding too early - this is the seller retention killer. Use deferred onboarding instead.
- Assuming Stripe handles UX - Stripe handles compliance. You handle the product experience.
Remember: Stripe handles compliance. You handle the product experience. The most common failure mode is founders thinking Stripe does more than it actually does.
Calculate Your Marketplace Revenue
Now that you understand how payments flow, model what your marketplace will actually earn. Factor in your commission rate, Stripe's processing fees, and your expected transaction volume.
Net Monthly Revenue
$276
After Prometora & Stripe fees
Annual Projection
$3,312
Net revenue at this volume × 12
Above Break-Even
36 orders
64 above — subscription covered
Your Settings
Per Transaction Breakdown
Deducted from seller
What you earn as marketplace owner
Seller side (for reference)
Monthly Projections
Yearly Projections
Like the look of $276/month?
Start a free 14-day trial and turn this projection into a real marketplace.
Revenue Growth Chart
Visualize how your net revenue scales with order volume
Monthly orders → Net revenue/month
Scaling Projections
See how your revenue grows as your marketplace scales (based on $50 AOV, 10% commission, Professional plan)
| Orders | GMV | Commission | Fees | Net |
|---|---|---|---|---|
| 50 | $2,500 | $250 | -$187 | $64 |
| 100Current | $5,000 | $500 | -$224 | $276 |
| 250 | $12,500 | $1,250 | -$337 | $914 |
| 500 | $25,000 | $2,500 | -$524 | $1,976 |
| 1,000 | $50,000 | $5,000 | -$899 | $4,101 |
Ready to Start Earning?
With 100 orders at $50 AOV, you could be earning $276/month. Start building your marketplace today.
Want to share projections with co-founders or save scenarios? Open the full Marketplace Revenue Calculator → Export to CSV or Google Sheets, share via link, and switch between plans to compare break-even.
Stripe Connect
Secure payments
SSL Encrypted
All data protected
30-Day Guarantee
Money back, no questions
Custom Domain
Your brand, your URL
Trusted by Marketplace Founders
“After trying independent developers and other platforms I decided to give Prometora a try to get my training marketplace site off the ground. I’m so happy I found Prometora - it was very easy to get started and has capabilities that far exceed those of the other platforms I tried. The support at Prometora has been incredible as Rasmus is constantly updating and improving the platform. Prometora is simple enough for beginner developers like me but powerful enough to bring any concept to reality.”
Elliott Cooper
Founder, Spotlox — Canadian training marketplace
“I wanted a reliable partner, and choosing Prometora was undoubtedly the best decision for developing Perigoodies. The team’s guidance and dedication made my job much easier, and their responsiveness and support far exceeded my expectations and are greatly appreciated.”
Nelly P.
Founder, Perigoodies — Périgord artisan & gourmet marketplace
Frequently Asked Questions
Regular Stripe is for one business collecting payments. Stripe Connect is for platforms that route payments between buyers and sellers.
On Prometora, Stripe's processing fees are the same - and we add a small platform transaction fee (2% on Starter, 1.5% on Professional, 1% on Business) on top.
Use Standard only if you want sellers to manage their own full Stripe accounts. Use Custom only if you have a dedicated engineering team and need complete control over the onboarding experience.
If you're starting fresh, consider building on the newer Accounts v2 API instead, where you compose these tradeoffs directly rather than picking a fixed type - see the v2 questions below.
The big benefit: one Account object replaces the v1 pattern of maintaining a separate Customer object whenever a connected account also needs to be charged. v1 isn't being deprecated, but Stripe recommends v2 for new platforms. See Stripe's Accounts v2 docs for the full reference, or watch my video breakdown of the v1-to-v2 migration above.
Stay on v1 if you're integrating with OAuth-authenticated connected accounts - v2 doesn't support that flow yet. Existing v1 platforms don't need to migrate; v1 isn't deprecated, though Stripe discourages maintaining both versions indefinitely.
Prometora supports deferred onboarding - sellers can create listings and even make sales before completing Stripe verification. Their earnings are tracked and automatically paid out once verification is complete.
This dramatically improves seller retention because sellers complete onboarding when they have real money waiting, not when they're still evaluating your platform. We've open-sourced the full implementation on GitHub.
Prometora handles the deferred holding, earnings tracking, and automatic payout on verification for you. Additional risk controls - volume caps before requiring onboarding, a transfer delay after verification to cover the dispute window, and platform-controlled refunds - are choices you tune to your own risk tolerance.
But the deferred window does briefly hold and direct seller funds, so the "control" question is arguable and how a regulator reads it is jurisdiction-specific (De Nederlandsche Bank in the Netherlands, BaFin in Germany, and so on).
Practical guidance for EU/EEA platforms: keep the hold window short, force onboarding before payout, never sweep the held balance into an operating account, and confirm your specific setup with Stripe and local payments counsel before relying on it.
For new connected accounts, Stripe may hold funds for a longer initial period (up to 14 days) as a fraud prevention measure.
Your marketplace should have a clear refund policy that defines who pays - the seller, the platform, or both - and what the timeframe is.
Check Stripe's supported-country list for the latest availability.
With Prometora, no coding is needed. Stripe Connect is pre-configured and ready to use out of the box.
Prometora uses Stripe Connect exclusively because of its reliability and comprehensive feature set.
In general, the marketplace platform is responsible for reporting, and individual sellers are responsible for paying their own taxes. Consult a tax professional for your specific situation.
Written by Rasmus Sørensen
Rasmus is the founder of Prometora, building AI-powered tools to help non-technical founders launch online marketplaces. After launching marketplaces like Nordic Mugs, NinjaBuzz, and My Spare Desk, he shares everything he's learned about building, launching, and growing marketplace businesses.
Related Guides
Keep going - these cover the next questions most marketplace founders have.
Tutorial
How to Build a Multi-Vendor Marketplace in 2026 (Step by Step)
From idea to first transaction without writing payment code or hiring a dev team
Marketplace Fundamentals
How to Start an Online Marketplace in 2026: 5-Step Playbook
The complete guide to going from idea to launch - without wasting months or money
Marketplace Growth
The Chicken and Egg Problem in Online Marketplaces - How to Solve It
15 proven strategies to break the cold start loop and get your first users
Ready to build your marketplace?
Turn your marketplace idea into reality. No coding required.
Start Free Trial