How to Build a Two-Sided Marketplace With Next.js and Stripe Connect -- Platform Payments and Seller Onboarding

You want to build a marketplace -- a platform where other people sell things and you take a percentage. Sounds straightforward until you read the Stripe Connect docs and realize marketplace payments work nothing like the subscription billing you have seen before.

The core difference: in a regular SaaS you collect money and keep it. In a marketplace, you collect money on behalf of sellers and forward most of it to them while keeping a platform fee. That distinction changes everything about how you structure payments, onboard sellers, and handle payouts.

Why Stripe Connect Exists

Stripe has three payment models. The one you probably already know -- direct charges to your own Stripe account -- works fine for SaaS subscriptions or selling your own products. Stripe Connect is the layer on top that lets your platform collect payments for other people.

For a marketplace, you almost always want Express accounts. They give your sellers a Stripe-hosted onboarding flow (so you do not have to collect tax forms yourself), and a Stripe-managed dashboard where sellers can see their payouts. The alternative, Custom accounts, gives you more control but means you are legally responsible for identity verification and compliance. Unless you have a compliance team, stick with Express.

What You Start With

If you are using this Next.js SaaS boilerplate, you already have:

• JWT auth and user accounts in Postgres via Neon DB
• Stripe Checkout and subscription billing pre-wired
• Email via Resend for confirmations and notifications
• A clean module structure to add seller, listing, and transaction models alongside your existing user module

The boilerplate is not pre-built as a marketplace -- but the foundation means you are not starting from auth and payments from scratch. You are adding Connect on top of a working product layer.

The Three Things You Need to Build

1. Seller onboarding

Every seller needs a Stripe Express account linked to your platform. The flow looks like this:

1. Seller clicks "Become a Seller" in your app
2. You call stripe.accounts.create({ type: express })
3. You store the returned account_id on the user in your database
4. You generate an onboarding link with stripe.accountLinks.create(...) and redirect the seller to Stripe
5. Seller completes Stripe's form (ID, bank account, tax info)
6. Stripe redirects back to your app; you check charges_enabled on the account to confirm they are ready

You also need a webhook listener for account.updated so you can update your database when a seller's status changes -- for example, when they finish onboarding days after clicking the link.

2. Split payments at checkout

When a buyer pays for a listing, you use a destination charge: the full amount goes to Stripe, Stripe sends most of it to the seller's Express account, and you keep your platform fee.

The key parameters are transfer_data.destination (the seller's account_id) and application_fee_amount (your cut in cents). A 10% platform fee on a $100 purchase looks like:

// Inside your Stripe Checkout session params
application_fee_amount: 1000,   // $10.00 in cents -- your platform cut
transfer_data: { destination: seller_stripe_account_id }

Stripe handles the split automatically. You do not manually transfer money.

3. Listing and transaction model

Your database needs at least three new tables:

• listings -- what sellers are selling (title, price, seller_id, status)
• orders -- each purchase (listing_id, buyer_id, stripe_payment_intent_id, amount, platform_fee)
• seller_accounts -- maps your user_id to the Stripe account_id and stores onboarding status

Add these as modules following the same pattern the boilerplate uses for users and posts. The service layer for orders should verify the listing is active and the seller's charges_enabled is true before creating the Checkout session.

The Decision You Have to Make First

Before you write a line of code, decide: what percentage do you take, and is it the same for everyone?

• Fixed platform fee (e.g. 10% of every transaction): simple, predictable for sellers, easy to reason about in code
• Variable fee by plan (free sellers pay 15%, premium sellers pay 5%): requires storing the fee rate on the user and passing it at checkout
• Per-listing flat fee instead of a percentage: simpler accounting but sellers prefer a percentage so their cost scales with revenue

Most early marketplaces start with a single fixed percentage. You can add tiers later once you know what conversion looks like at different rates. See the Stripe subscriptions guide if you want to add premium seller plans alongside Connect.

What a Weekend Build Looks Like

If you start from this Next.js boilerplate, a basic marketplace -- seller onboarding, listing creation, buyer checkout with a split payment -- is a focused weekend build:

• Day 1: seller module (schema, onboarding route, Express account creation, status webhook)
• Day 2: listing module, checkout route with destination charge, order confirmation email

You are not building auth, database migrations, email infrastructure, or Stripe webhook plumbing from scratch. Those are already done. The work is scoping the marketplace-specific logic, not the foundation.

If you want to see what a product-specific build looks like on this stack, the directory website walkthrough shows the same pattern -- a specific product type added on top of the boilerplate -- even though directories use direct payments rather than Connect.

Start With the Seller Onboarding

The bottleneck in any marketplace is getting sellers paid. If sellers cannot receive payouts, nothing else matters. Build the onboarding flow and the account.updated webhook listener first, confirm you can create a test Express account and flip it to active in Stripe's test mode, then add listings and checkout.

Get the boilerplate, deploy it to Vercel, and you are one module away from a working marketplace: https://boilerplate.iteam-company.com.