Reversing a transfer after the seller has been paid out

What happens at payout

On the scheduled payout date, Stripe sweeps the connected account’s available balance to their bank. From that moment the funds are outside the system entirely: no API call can retrieve them, and no reversal can pull them back from a bank account. Yet the transfer object still shows an unreversed balance, because from the ledger’s point of view the transfer remains outstanding.

This is why post-payout findings look identical to live ones until you act. The arithmetic is unchanged; only the physics has changed.

The post-payout reversal

If you create the reversal anyway, Stripe accepts it and drives the connected account’s balance negative. Recovery then happens only through the account’s future inbound volume: incoming charges are diverted, future transfers are reduced, payouts are withheld until the debt clears. Stripe never debits the seller’s bank account directly.

For an active seller this often resolves within weeks. For a dormant or churned seller it resolves never — the negative balance just sits there as a number neither side looks at.

What that does to your recovery rate

Modelled honestly: recovery odds decay with every payout cycle that passes between refund and action. An active seller transacting weekly will usually absorb a modest negative quickly; a seller who churned last month will never generate the offsetting volume at all. The decay curve differs per marketplace — daily-payout gig platforms decay brutally, net-30 wholesale platforms barely — which is why we publish the method rather than a universal percentage. Plot it against your own payout schedules and the shape becomes obvious.

Netting instead of reversing

Where your seller terms allow setoff, deducting the owed amount from the next transfer you would create anyway recovers the same dollars without touching a negative balance. The transfer still goes out; it is just smaller, and — critically — the seller was told before, not after.

const adjusted = Math.max(0, nextTransferAmount - owed);
await stripe.transfers.create({ destination: acct, amount: adjusted });

When to write it off — and what FeeGuard does

Dormant account plus pursuit cost above expected value is a finance decision, not an admission of failure. Book the write-off against the same line the leak came from, close the finding with its evidence intact, and move on. FeeGuard’s job is upstream of all of this: detection runs on events as they arrive, which is precisely how findings land while balances are still positive. When they do land late, the queue separates recover-now from net-later from write-off, each carrying the figure and transaction ids the next step needs.