Fee leaks on marketplaces: every refund is a three-way split you are losing by default

The marketplace refund profile is different

Marketplace refund rates run higher than straight e-commerce — buyers cannot inspect goods before purchase, seller quality varies, and disputes get emotional faster. Partial refunds are disproportionately common thanks to multi-item baskets where one item survives. Both facts matter mechanically: higher refund incidence multiplies every per-refund leak, and partial-heavy mixes concentrate leakage in exactly the rounding-and-proportionality corner where naive implementations fail.

Dispute rates concentrate too: a minority of sellers generates a majority of chargebacks. That concentration is good news operationally — watch-lists work — provided anyone is generating the list.

Vector one: the unreversed transfer

On a $100 basket with a $10 take rate, the seller received $90. Buyer refunded in full: your balance pays out $100 while the seller’s $90 sits untouched unless reverse_transfer was set. Nothing errored; the API returned success; your ledger will disagree with Stripe by exactly $90 at month-end, attributed to nothing. Multi-seller baskets multiply this by leg count — three vendors on one order means three opportunities for the flag to go missing, which is why basket-heavy marketplaces see aggregate leakage that looks impossible per-order.

Vector two: the fee that stayed attached

refund_application_fee also defaults false. Keeping your cut on refunded revenue inflates effective take rate in ways finance discovers only when reconciling refunds against fees: a nominal 10% take becomes roughly 16.7% of surviving revenue once 40% of orders refund and fees never return. Sometimes that is deliberate policy; more often it is an accident contradicting published terms — and either way it should be a number someone chose.

Vectors three and four: disputes and conversion drag

Lost disputes debit the platform in full plus the dispute fee while the seller keeps the transfer — fraud-ring sellers make this worse by cashing out before adjudication. Payout schedules accelerate the damage: daily payouts drain recoverable balances before dispute.closed arrives. Cross-border marketplaces add vector four silently: settlement-currency conversions carry spread on every transfer, and misconfigured payout currencies persist for quarters because nothing ever fails.

Who owns the gap between engineering and finance

Engineering owns webhooks; finance owns month-end; nobody owns the space between, which is precisely where these four vectors live. Month-end reconciliation does eventually catch them — after payout windows close, converting recoveries into write-offs. The operational fix is moving detection next to the events instead of next to the calendar.

What FeeGuard does about it

Four detectors cover exactly these vectors, running on the eight webhook events marketplaces already emit, scoring findings so ops works the queue instead of the spreadsheet. Detection and the 90-day lookback are free; the audit takes minutes with pasted data or ten with a read-only key, and it returns dollars-by-cause rather than anxiety.