Chapter 5 · Disputes and chargebacks on Connect
The Platform Refund Ledger · 6 min read
This chapter answers one question: when a buyer's issuer reverses a charge, which account does Stripe debit on each charge pattern, who pays the dispute fee, and what can the platform still recover?
Disputes are refunds with worse timing, an extra fee, and a decision deadline. On Connect they also have an allocation rule that most platforms have not read.
Who gets debited
Stripe's Connect disputes documentation draws one bright line (docs.stripe.com/connect/disputes):
| Pattern | Disputed amount debited from | Dispute fee debited from |
|---|---|---|
| Direct charges | the connected account's balance, always attempted there first; shortfall responsibility follows your negative-balance setting (controller.losses.payments / v2 defaults.responsibilities.losses_collector) | depends on the account's configuration (controller.fees.payer and equivalents): either party |
| Destination charges | your platform account | your platform account |
| Separate charges and transfers | your platform account | your platform account |
Two documented details belong next to that table. First, on_behalf_of changes nothing about liability — the debit rule applies "with or without on_behalf_of," so making the seller the settlement merchant does not move the chargeback off your books. Second, nothing reverses automatically: the same page recommends listening for charge.dispute.created and then attempting recovery yourself "by reversing the transfer through the Dashboard or by creating a transfer reversal." The seller keeps their payout unless you act.
What a dispute does to the ledger
Stripe deducts the disputed amount at creation, pending outcome, and books it as balance transactions of type adjustment whose source is the dispute object; winning returns the funds through another adjustment (docs.stripe.com/reports/balance-transaction-types). The Dispute object itself carries amount (the disputed value), status — progressing through states like needs_response, under_review, and ending in won or lost — plus evidence, an evidence_details response deadline, and balance_transactions, the itemized list of every ledger movement the dispute caused.
A lost dispute, worked to the cent
The book's running example at marketplace scale: a $860.00 destination charge priced with a $129.00 application fee — withheld from the transfer, so transfer.amount is $731.00 (chapter 1) — paid out to the seller, then charged back and lost. The $15.00 dispute fee is illustrative throughout — it varies by account configuration and region.
| Leg | No clawback | Clawback only | Clawback + fee returned |
|---|---|---|---|
| Charge | +$860.00 | +$860.00 | +$860.00 |
| Transfer to seller (fee withheld) | −$731.00 | −$731.00 | −$731.00 |
| Dispute lost: amount | −$860.00 | −$860.00 | −$860.00 |
| Dispute fee | −$15.00 | −$15.00 | −$15.00 |
| Transfer reversal | none | +$731.00 | +$731.00 |
| Fee returned to seller | none | none | −$129.00 |
| Platform position | −$746.00 | −$15.00 | −$144.00 |
Add each column down; every one sums. Three outcomes from one lost dispute:
- No clawback: the platform eats the entire charge and the fee — down $746.00 on a sale whose upside was ever only $129.00.
- Clawback alone: the platform is out exactly the dispute fee, $15.00, and the seller is back to zero, having returned precisely the $731.00 they received and not a cent more. Both parties' economics match what the card networks intend. It still needs a terms basis and a communication plan (chapter 10) — a seller who has already banked the money experiences this as a debit whatever the arithmetic says — but the arithmetic itself is clean.
- Clawback plus returning the fee: −$144.00, because the $129.00 fee refund lands on top of a reversal that had already squared the seller, who finishes +$129.00 on a sale the issuer took back. Chapter 3's
refund_application_feeparameter on reversal calls makes this easy to do by reflex; chapter 6 shows the identical trap on ordinary refunds.
Getting the recovery amount right
The recoverable figure from the seller is always:
Recoverable = transfer.amount − amount_reversed
Never dispute.amount. On this example the two differ by exactly the fee: $731.00 was transferred against an $860.00 dispute, and asking for $860.00 fails outright, because you cannot reverse more than you transferred. That gap is not an edge case — it opens on every destination charge carrying a fee, and wider still on separate-pattern sales or anything priced with transfer_data[amount]. And never add the dispute fee to the ask: the fee was never the seller's money. If the dispute resolves partially, read what actually moved from the dispute's balance_transactions rather than assuming any fraction.
Evidence, deadlines, and the exposure window
For destination and separate patterns the platform responds to the dispute; on direct charges the connected account is the respondent, though platforms routinely assist through shared tooling or embedded components (docs.stripe.com/connect/disputes). Evidence has a hard deadline exposed on the dispute object; missing it converts needs_response into a loss administratively rather than on the merits.
The financially decisive interval, however, runs from charge.dispute.created to the seller's next payout. At creation your platform is already debited (table above); the transfer is untouched; every payout cycle that passes converts reachable recovery into receivable. Reversing early carries a real trade-off that should be chosen, not stumbled into: if you later win, you may owe the seller their money back via a fresh transfer — and Stripe cautions that retransferring after a reversal is subject to cross-border transfer restrictions, which is why its own guidance suggests waiting until a dispute is actually lost for cross-border destination charges settled on behalf of the seller (docs.stripe.com/connect/destination-charges).
[DIAGRAM: One dispute, three clocks]
Horizontal timeline, day 0 to day 45.
Day 0: charge +$860; fee $129 withheld; transfer $731 to seller.
Day 2: seller payout #1 (funds leave reach).
Day 24: charge.dispute.created -> vertical red bar labeled "platform
debited $860 + $15 now"; second axis starts: "evidence clock" to
deadline marker around day 38.
Parallel green band under the timeline labeled "recovery window":
narrows at each payout tick (day 2, 5, 8, ...), annotated
"recoverable = transfer.amount - amount_reversed".
Day 38: charge.dispute.closed status=lost -> debit permanent.
End caption: three clocks ran simultaneously -- payout clock,
evidence clock, recovery window. Only one of them is yours to manage.
What to check on your own platform
- List disputes from the last 90 days; for each, record whether a transfer existed and how much of it was reversed before closure.
- Compute recoverable = transfer.amount − amount_reversed for every closed-lost dispute and total it — that number is the chapter 8 audit's third leak signature.
- Confirm who actually responds to disputes in each pattern, and where the evidence deadline is monitored.
- Decide and document the early-reversal question (reverse on
createdversus wait forclosed) against your real win rate. - Check whether
debit_negative_balancesinteracts with your dispute exposure — an auto-debited seller bank account is a support event whether or not it was planned.
Sources: docs.stripe.com/connect/disputes · docs.stripe.com/connect/destination-charges · docs.stripe.com/reports/balance-transaction-types