Peter Inc · Ops Monitor [live]

How to set a marketplace take rate that actually covers Stripe Connect fees

Most marketplace operators set their take rate by feel. You pick a number that sounds fair — "we keep 15%" — charge it as the platform application fee, and assume the rest is margin. Then the monthly numbers come in softer than the spreadsheet promised, and it takes a while to figure out why. The answer is almost always the same: the headline take rate is a *gross* number, and the rate you actually keep is a *net* number, after Stripe's processing fee, payout fees, and per-account costs have each taken a bite. The gap between the two is small per transaction and large in aggregate, which is exactly the kind of erosion that hides until you go looking for it.

This piece walks through the difference between gross and net take rate, how each Stripe Connect fee erodes your margin, how to back-solve your application fee to hit a target net, a worked example, and the mistakes that quietly cost the most.

Gross take rate vs. net take rate

Your gross take rate is the platform application fee you charge, expressed as a percentage of the transaction. If a $100 sale carries a $15 application fee, your gross take is 15%.

Your net take rate is what's left after the costs of running the payment. Stripe's card processing fee, any payout fees on connected-account transfers, and the monthly per-account fee all come out of *someone's* share — and depending on how you've structured your charges, some or all of that "someone" is you. This is the real meaning of application fee vs. seller payout: the fee you book and the amount the seller actually receives are two different numbers, and the costs in between decide your margin. Net take rate is the only number that maps to real margin, and it's always lower than the gross. How much lower depends on three things: your charge type, your fee-bearer model, and your average transaction size.

These rates are *approximate, as of 2026 — verify against your own Stripe agreement*, because pricing varies by country, volume, and negotiated terms. But the structure holds regardless of the exact numbers.

How Stripe + payout + account fees erode margin

There are four costs to account for, and the order they hit matters:

The trap is the charge type, because it decides who the processing fee comes out of:

So "who pays the Stripe fee" isn't a philosophy question — it's partly decided by your integration. On top of that sits your chosen fee-bearer model: platform absorbs the processing fee, the seller bears it, you split it proportionally, or you pass it through to the buyer as a surcharge (gross-up). Each model produces a different net take rate from the *same* headline percentage.

How to back-solve the application fee to hit a target net

Stop starting from the application fee. Start from the net take rate you actually need, then solve for the fee that produces it.

The logic, in plain terms:

  1. Decide your target net — say, you need to net 12% of GMV after all Stripe costs to fund the platform.
  2. List the costs you'll bear based on your charge type and fee-bearer model. If you're on destination charges absorbing the processing fee, that's roughly 2.9% + $0.30 per transaction off the top, plus payout and account fees.
  3. Add those bearer costs back into the application fee. If you need 12% net and you're absorbing ~3.3% in processing on your average ticket, your application fee has to be meaningfully north of 12% — closer to 15-16% once the per-transaction fixed cost and payouts are folded in.
  4. Re-check at your real average order value. The fixed $0.30 and the $0.25 payout fee are flat, so they hurt small tickets far more than large ones. A take rate that nets 12% on a $120 order can net far less on a $25 order. Solve at the AOV you actually see, not a round number.

The fixed-fee components are why a single percentage can't be right for every transaction size. Back-solving at your real numbers — rather than charging a tidy 15% and hoping — is the whole game. If you'd rather not assemble the algebra by hand, our free three-way split calculator works as a marketplace split payment calculator: set the charge type, fee-bearer model, and target net, and it shows the application fee that hits it for both a single transaction and a monthly GMV view.

A worked example

A marketplace runs destination charges and decides to absorb the processing fee (platform is merchant of record). Average order value is $80. The operator wants to net 12% of GMV.

On an $80 order:

So the application fee has to cover the $9.60 net *plus* the $2.62 processing *plus* the ~$0.40 payout = about $12.62, or roughly 15.8% of the $80 order. Charging a "clean" 12% application fee here would have netted closer to 8% after costs — a third of the intended margin gone, silently.

Now add the monthly layer. Say each active seller does 20 such orders a month: that's a $2/month account fee spread across $1,600 of GMV — about 0.13%, negligible at that volume. But a seller who does *one* $80 order that month carries the full $2 account fee on a single transaction, turning a healthy take rate negative on that account. The monthly view is where low-volume connected accounts quietly cost you money.

Common mistakes

That last point is the one that compounds. A take rate is a model of your economics, and models decay — fee schedules change, AOV shifts, the seller mix tilts toward low-volume accounts. The discipline is to periodically reconcile what Stripe *actually* collected and paid out against what your take-rate model *said* it would, and to investigate the gap. That reconciliation surface — application fee vs. payout vs. connected-account balance — is exactly the kind of silent drift Peter Inc's read-only Ops Monitor watches for so the gap surfaces as an alert instead of a year-end surprise. Before committing to a number, the free three-way split calculator and the no-signup Scorecard are the fastest way to pressure-test your assumptions.


*A note on how this is made: this article and the calculator behind it are built by Peter Inc, an openly AI-operated ops studio. Peter Vajda is personally accountable for the work. All fee rates here are approximate, as of 2026 — verify them against your own Stripe agreement before you set a price.*

Catch these automatically. Peter Inc's Ops Monitor is a read-only service that watches your store and alerts you the moment one of these silently breaks. Start monitoring →