Who pays the Stripe fee in a Connect marketplace? (direct vs destination charges, and the split that follows)

If you run a marketplace on Stripe Connect, there's a question that sounds simple but quietly decides your margins: when a buyer pays $100, who actually eats the Stripe processing fee — you, the seller, or the buyer? The answer isn't a setting you toggle. It's a consequence of which charge type you use, plus the fee-bearer model you bolt on top. Get it wrong and your "10% take rate" can turn out to be 6.8% — or your sellers can quietly net less than they expected and churn.

This piece walks through where the fee is deducted, how the application fee layers in, and the four ways the split can shake out, with a worked example you can check against your own numbers.

The three fees in play

Before charge types, get the fees themselves straight. For US accounts these are *approximate as of 2026 — verify against your own Stripe agreement, since negotiated and regional rates vary*:

• Card processing fee: ~2.9% + $0.30 per successful charge. This is the one everybody argues about who pays.
• Platform application fee: whatever percent and/or fixed amount *you* set. This is your revenue.
• Connect account + payout fees (Express/Custom): ~$2/month per active connected account, and ~0.25% + $0.25 per payout, with roughly +1% on cross-border/FX. Small per-transaction, but they add up at volume and they come out of *someone's* net.

The processing fee is the interesting one because, unlike the others, *you don't choose who pays it directly*. The charge type does.

Charge type decides where the processing fee is deducted

Stripe Connect has two charge patterns that matter here, and they put the merchant of record in different places.

Direct charges. The charge is created *on the connected account*. The connected account is the merchant of record. That means Stripe's processing fee comes out of the connected account, and your application fee is pulled from the connected account too. You never see the $3.20 hit your own balance — it's deducted upstream, from the seller's side, before they net anything.

Destination charges (and separate charges-and-transfers). The charge is created *on your platform account*. You are the merchant of record. Stripe's processing fee comes out of your platform balance. You then transfer the seller's share to their connected account. Whether the seller feels the processing fee at all now depends entirely on how you size that transfer.

That's the whole crux: direct = seller's side absorbs the processing fee by default; destination = your platform absorbs it by default, unless you deliberately shift it in the transfer math.

The four fee-bearer models

"Who pays the fee" then becomes a design choice you make on top of the charge type:

• Platform absorbs: you eat the processing fee out of your cut. Cleanest story for sellers, smallest margin for you.
• Seller bears: the fee is deducted from the seller's payout (the default for direct charges; an opt-in for destination charges where you net the fee out of the transfer).
• Proportional: platform and seller split the fee in proportion to their shares of the gross.
• Buyer pass-through: you gross-up the charge so the buyer pays a surcharge that covers the fee — note the surcharge itself is part of the gross, so it gets charged ~2.9% too, and surcharging may be restricted by card-network rules or local law.

The model and the charge type interact. You can build "seller bears" on a destination charge — you just have to do the arithmetic yourself in the transfer amount, because Stripe won't do it for you the way it does on a direct charge.

A worked example: the same $100, three very different outcomes

Buyer pays $100 gross. Your application/take rate is 10%. Processing fee is 2.9% + $0.30 = $3.20. Ignore monthly account and payout fees for clarity (they'd shave a little more off whoever's net they hit).

Case 1 — Direct charge (seller's side bears the fee).

• Processing fee ($3.20) and your application fee ($10.00) both come out of the connected account.
• Connected account net: $100 − $3.20 − $10.00 = $86.80
• Platform net: $10.00 (your application fee, untouched by the processing fee)
• Effective take rate: $10.00 / $100 = 10.0%

Case 2 — Destination charge, platform absorbs the fee.

• You're merchant of record, so the $3.20 comes out of *your* balance.
• You transfer the seller's $90 share; you keep the rest after the fee.
• Seller net: $90.00
• Platform net: $100 − $3.20 − $90.00 = $6.80
• Effective take rate: $6.80 / $100 = 6.8%

Case 3 — Destination charge, seller bears the fee.

• Same charge type as Case 2, but you net the processing fee out of the transfer: you transfer $90 − $3.20 = $86.80.
• Seller net: $86.80
• Platform net: $100 − $3.20 − $86.80 = $10.00
• Effective take rate: 10.0%

Cases 1 and 3 land the platform in the same place — 10% net — by completely different mechanisms. Case 2 is the trap: a destination charge built the "obvious" way silently donates your processing fee to the seller, turning a 10% headline into a 6.8% reality. Across thousands of transactions that 3.2-point gap is the difference between a business that works and one that doesn't.

You can run all four models — including the buyer pass-through gross-up — against your own rates in the free three-way-split calculator: single transaction or a monthly view from GMV, transaction count, and active account count.

What this means for a platform operator

A few practical takeaways:

• Your headline take rate is not your effective take rate. The processing fee, account fees, and payout fees all sit between them. Always compute the net, not just the percentage you advertise.
• Pick the fee-bearer model on purpose, then verify it in a live test charge. Don't infer it from a dashboard label — push $1 through and read the actual balance transactions and transfer amounts.
• Watch the small recurring fees at volume. $2/account/month and $0.25 per payout look like rounding errors on one transaction and like real money across a thousand sellers and their payouts.
• Cross-border adds ~1%. If your sellers or buyers span currencies, that surcharge changes which model keeps you whole.
• Reconcile continuously. The fee math being *correct* on paper doesn't guarantee application-fee revenue, transfers, and connected-account balances actually agree week to week — that reconciliation is exactly the silent surface where Connect platforms lose money without an error ever showing up. That last surface is the one Peter Inc's read-only Ops Monitor watches: it reconciles application-fee revenue against transfers and connected-account balances so a drift surfaces as an alert instead of a year-end surprise.

Decide who bears the fee deliberately, prove it with a real charge, and keep an eye on the reconciliation. The marketplaces that get burned aren't the ones with a bad rate — they're the ones who assumed the default split was the one they'd chosen. Before you commit, the free three-way-split calculator and the no-signup Scorecard are the fastest way to pressure-test which model actually keeps you whole.

*A note on how this is made: this article is published by Peter Inc, an openly AI-augmented ops studio. Peter Vajda is personally accountable for it and reachable at [email protected]. All fee rates above are approximate, as of 2026, and editable in the calculator — verify them against your own Stripe agreement.*