Marketplace Payments with Stripe Connect: Account Types, Charges & Payouts (2026)

When do you actually need Stripe Connect (not plain Stripe)?

You need Stripe Connect the moment money has to land in someone else’s account. Plain Stripe assumes you collect for yourself; Connect lets a platform pay out third-party sellers. You pick an account type (Standard, Express, or Custom), onboard sellers via Stripe-hosted Connect Onboarding for KYC, then run destination charges where your cut is the application_fee_amount.

The line is structural, not cosmetic. Plain Stripe assumes you are the single merchant collecting for yourself — and I walked through that exact single-merchant setup in How to integrate Stripe into your SaaS. Connect assumes a platform sitting in the middle of a transaction between a buyer and a seller who is not you. The instant funds must reach a business that isn’t yours, plain Stripe can’t model the split — and that’s the wall you hit.

This is exactly the problem I ran into building Mercanto, a B2B wholesale marketplace. Wholesalers needed to get paid for their orders, I needed my commission off the top, and a single Stripe account simply can’t express “this $100 belongs mostly to that seller and partly to me.” That’s three new jobs stacked on top of normal Stripe: onboarding sellers (KYC), deciding who is the merchant of record on each charge, and moving money out to sellers (payouts).

One thing carries over unchanged from the single-merchant world: the same source-of-truth discipline. You grant capabilities and settle commissions only on signature-verified webhook events, never on a redirect or a hopeful client call. If you want the deeper argument for why events beat polling for this, I made it in Webhooks vs polling vs API. Official anchor: the Stripe Connect docs.

Standard, Express, or Custom — which Connect account type fits?

Connect gives you three account types, and the whole decision is a single tradeoff: control versus effort.

Standard — the connected account has a full Stripe account plus its own dashboard, and it manages its own onboarding and disputes. This is the least platform effort, but it’s Stripe-branded (Shopify is the classic example). Good when your sellers are sophisticated businesses who are fine seeing Stripe and running their own back office.

Express — Stripe-hosted onboarding plus a lightweight Express dashboard. The platform controls more of the experience, and this is the common default for marketplaces. You get a branded-enough flow and Stripe-hosted KYC without building dashboards yourself.

Custom (a.k.a. Connect embedded components / controller configuration) — the platform fully owns the UX, and the seller may not even know Stripe is involved. This is the most work and the most control.

So the axis is clean: Standard sits at least-effort / least-control, Custom at most-control / most-work, and Express lands in the sweet spot between them.

My decisive call, and I’ll label it as opinion: start with Express. It hands you a branded flow and Stripe-hosted KYC without making you build seller dashboards or own a dispute UI. Reach for Custom only when the seller experience is your product — when an embedded, white-label payouts surface is a feature you’re selling, not a chore you’re avoiding. Otherwise Custom is a lot of UX engineering for control you won’t miss.

How do you onboard sellers without building KYC yourself?

Here’s the part you should be most relieved about: you do not build identity verification. You use Stripe-hosted Connect Onboarding via account links, and Stripe handles KYC, identity verification, and compliance. You redirect the seller and Stripe carries the regulatory weight.

The shape is two steps. First create the connected account, then create an account link and send the seller to Stripe’s hosted onboarding flow.

// Step 1: create the connected account (one per seller)
const account = await stripe.accounts.create({ type: 'express' });

// Step 2: send the seller to Stripe-hosted Connect Onboarding
const accountLink = await stripe.accountLinks.create({
  account: account.id,
  type: 'account_onboarding',
  refresh_url: 'https://yourapp.com/connect/refresh',
  return_url: 'https://yourapp.com/connect/return',
});

// redirect the seller to accountLink.url

The two URLs do different jobs. refresh_url handles an expired or abandoned link — Stripe sends the seller there and you mint a fresh link. return_url is where Stripe sends the seller when they’re done. But treat return_url exactly like Checkout’s success_url: returning is a UX signal, not proof that onboarding actually finished. A seller can bounce back with required fields still missing.

So do not grant a seller the ability to receive payouts off the back of a redirect. Wait for a webhook to confirm the account is fully onboarded and its capabilities are active — the same webhook-as-truth discipline from the subscription post. Identity and compliance are precisely the part you don’t want to own; let Stripe tell you when it’s genuinely done.

Direct, destination, or separate charges & transfers — which charge type?

The second core decision is how the charge is structured. There are three options, and they differ on who is the merchant of record and who pays the Stripe fee.

Direct charge — created on the connected account. The connected account is the merchant of record and pays the Stripe fee; the platform takes its application_fee_amount off the top. This fits when the seller is clearly the merchant — a Standard-style setup where the buyer is effectively transacting with the seller’s business.

Destination charge — created on the platform, with funds auto-transferred to the connected account via transfer_data[destination]. Here the platform is the merchant of record, and the platform takes application_fee_amount. This is the best fit for most marketplaces.

Separate charges & transfers — the platform charges the customer, then issues separate transfers to one or more connected accounts. It’s the most flexible option because you can split a single order across multiple sellers, but it’s also the most manual.

My decisive default: destination charges for most marketplaces. You control the customer relationship and the checkout, you’re the merchant of record, and the money still lands with the seller automatically. Reach for separate charges & transfers only when one customer payment has to split across multiple sellers — a multi-vendor cart — which is exactly the Mercanto case, where a single buyer order pulls line items from several wholesalers at once. Official anchor: how charges work.

How does application_fee_amount become your take rate? (the code)

application_fee_amount is your commission on a charge — and the single most important thing to internalize is that it’s an amount in the smallest currency unit, not a percentage. Stripe doesn’t take a percent; you compute the cut yourself and pass the exact figure.

Here’s a destination charge with your take built in:

// $100 order, 10% platform take
const amount = 10000;                            // $100.00 in cents
const applicationFee = Math.round(amount * 0.10); // 1000 = $10.00, always an integer

const paymentIntent = await stripe.paymentIntents.create({
  amount,
  currency: 'usd',
  application_fee_amount: applicationFee,
  transfer_data: { destination: connectedAccountId },
});

Note the Math.round: application_fee_amount must be an integer in the smallest currency unit, so guard against fractional cents the moment your take rate or order amount stops being round. Walk the split: on that $100 order with a 10% take, amount = 10000 and application_fee_amount = 1000. The seller’s connected account receives the remainder, and your platform keeps the 1000. That’s the whole money mechanic.

Two rules I treat as non-negotiable. First, compute application_fee_amount server-side from your own commission rule — never trust a client-supplied number, the same way you never trust a client-supplied customer ID in a subscription flow. A take rate posted from the browser is a take rate an attacker can set to zero. Second, reconcile against signed webhook events before you treat a commission or a payout as real. The money settles asynchronously; the event is what confirms it.

How do payouts to sellers actually work?

Once a charge settles, the seller’s share lands in their connected-account balance and Stripe pays it out to their bank account. You do not move money manually — Stripe runs the payout rails. Your job is to set things up correctly and then surface status; Stripe does the transfers.

Reach matters here: payouts reach 50+ countries. For a cross-border marketplace where your sellers aren’t all in one country, that’s the difference between a global roster and a domestic one.

The charge type you chose earlier decides who holds the funds first. With a direct charge, funds start on the connected account. With a destination charge, funds start on the platform and are auto-transferred to the seller. With separate charges & transfers, you transfer explicitly. Either way the end state is the same — the seller’s balance gets paid out — but the path differs.

Payout timing, schedule, and the connected account’s balance all live in Stripe. For Express and Custom you can surface this inside your own product; for Standard the seller just sees it in their own dashboard.

A hard-won practical note from Mercanto: sellers care about payout timing more than almost anything else. “Where is my money?” was the number-one seller support question, full stop. Set expectations up front and surface payout status in your UI, because if a seller can’t see when their money is coming, they will ask you — every single time.

What does Stripe Connect actually cost in 2026?

Same cost-honesty energy as the SaaS post: model the full stack before you set your take rate. As of 2026 — and you should confirm current pricing on Stripe’s page, because these figures move — your cost is standard processing plus Connect fees layered on top.

The honest takeaway: your real cost is processing + per-account + payout, all stacked. Your application_fee_amount has to clear that entire stack and still leave you margin. If you set a 5% take and never modeled the per-account and payout fees underneath it, you can quietly run a marketplace at a loss on low-value orders.

Payouts reach 50+ countries, but cross-border and per-region specifics change the math, so confirm the numbers on the official page rather than trusting these as gospel. Official anchor: Connect pricing. Treat every fee figure here as time-sensitive and verify it.

FAQ: Stripe Connect for marketplaces

Standard vs Express vs Custom in one line? Standard = the seller owns its Stripe account and dashboard (least platform effort); Express = Stripe-hosted onboarding plus a lightweight dashboard (the marketplace default); Custom = you own all the UX and the seller may not know Stripe is involved (most work).

Which charge type should I default to? Destination charges. The platform is merchant of record, funds auto-transfer to the seller, and you take application_fee_amount. Use separate charges & transfers only when you need to split one payment across multiple sellers.

Do I have to build KYC / identity verification? No. Stripe-hosted Connect Onboarding via account links handles KYC and compliance — you redirect the seller and Stripe does the identity verification.

How do I take my commission? Set application_fee_amount on the charge. It’s an amount, not a percent, so you compute the cut yourself. On a destination charge the rest transfers to the seller automatically.

How many countries can I pay out to? Payouts reach 50+ countries. Confirm current coverage and per-region fees on Stripe’s pricing page, since cross-border details change the math.

Closing: ship the boring, correct marketplace

One breath: start with Express, use Stripe-hosted onboarding for KYC, run destination charges for most marketplaces, make application_fee_amount your cut, and let Stripe handle the payouts. That’s the whole spine.

The webhook-as-source-of-truth rule still governs everything. Confirm a seller’s onboarding only on a signed event, and settle commissions only on signed events — never on a redirect, never on a hopeful client call. Money mechanics settle asynchronously, and the event is the only thing that tells you the truth.

This is the architecture behind the real marketplace payouts I shipped on Mercanto. Boring and correct keeps money flowing to the right accounts while you sleep — which is exactly what you want when other people’s money is moving through your platform. If you’re scoping a build like this, I sketched how to think about the budget in How much does it cost to build a SaaS MVP.

If you want a hand wiring this up, that’s the kind of work I do in SaaS development.