Recovery playbook
Clawing back a lost dispute from the seller
A buyer disputes a $600 order and wins. Stripe debits your platform $600 plus a $15 dispute fee. The seller who received $540 of the original sale is untouched by any of it. Unless you reverse that transfer, you have funded a chargeback on a sale you netted $60 from — and the clock is running, because every payout cycle converts retrievable funds into a claim on future volume. This playbook fixes the moment, the amount, and the rules of engagement.
The debit, precisely
Worked end-to-end on a destination charge so there is no ambiguity about who owes what to whom:
- Disputed amount debited from platform
- −$600.00
- Dispute fee (never recoverable)
- −$15.00
- Application fee kept
- +$60.00
- Position before clawback
- −$555.00
- Genuinely recoverable from seller
- $540.00
- Net loss after successful recovery
- −$15.00
The right amount
Recoverable = transfer.amount − amount_reversed. Not the disputed amount — that overstates the target by exactly your own application fee, and Stripe rejects reversals exceeding the transfer. Never include the dispute fee; it is platform cost and cannot be passed to the connected account, so including it guarantees failure on every case. On partial wins, read the actual debit from the dispute’s balance transactions rather than trusting dispute.amount — the two differ more often than teams expect, and over-recovering from a seller is a complaint you will lose.
The right moment
Treat charge.dispute.created as the watch-list event: funds are still at risk, the seller has probably not been paid out, and every option remains open. Act on charge.dispute.closed with status lost while the balance is still reachable — hours matter, weeks destroy. Fraud reason codes are the standing exception to waiting: they are rarely won, and reversing early on them is closer to inevitable than premature. The trade-off on open disputes is real and deliberate — reversing early penalises a seller who may yet win, so most platforms hold and monitor instead.
Gating that keeps it fair
Four rules keep automated recovery defensible: never automate an open dispute; never automate an ambiguous charge where both levers were already applied; set a floor below which you absorb because conversation costs exceed recovery; put recovery rights in seller terms before relying on them. Automation without these gates is not efficiency — it is a way to lose your best vendors quickly.
Idempotency, and what FeeGuard does
Derive the idempotency key from the dispute id so retries collapse harmlessly; note keys expire after 24 hours, so workers must additionally read live state before acting. FeeGuard raises findings on both dispute events with the recoverable figure pre-computed from live transfer state, gates auto-clawback to realised losses with unambiguous net position at risk score ≥70, and always leaves open disputes for a human decision.
Common questions
Can we recover the $15 dispute fee from the seller?
No. It is platform cost under the network rules and cannot be passed to the connected account — including it in the reversal amount simply guarantees the call fails.
What if we win the dispute later?
Funds return through the normal dispute flow. This is exactly why pre-clawing open disputes is prohibited in every sane policy: you would be debiting a seller for a dispute they went on to win.
Does on_behalf_of shift liability to the seller?
No. Teams set it believing it does and discover otherwise during their first significant dispute month. Destination charges put liability on the platform regardless of on_behalf_of.