Definition
What is a destination charge?
A destination charge is created on the platform account with `transfer_data[destination]` pointing at a connected account: the buyer’s full payment lands on the platform balance, the application fee skims off, and the remainder transfers immediately to the seller. It is the most common marketplace pattern because it gives platforms unified control — refunds, disputes, statements — and it carries the corresponding liability: the platform is merchant of record for everything downstream.
The flow, in order
Payment authorises and captures onto platform balance → application fee splits off → transfer fires immediately for amount minus fee. Three objects, one instant. Refund behaviour then follows platform-liability rules: buyer refunded from platform, seller transfer untouched unless flagged, fee retained unless flagged.
Versus the alternatives
Direct charges: created on the connected account; seller is merchant of record; simpler liability, weaker platform control. Separate charges & transfers: platform charges and transfers independently — escrow-friendly, maximally manual. Destination sits between: automated like direct, liable like separate. Most marketplaces choose it for the control; few read the liability fine print first.
Why it dominates leak discussions
Because platform liability plus automatic transfers equals the unreversed-transfer failure mode: every refund has a paired transfer to reverse, and defaults decline to do it. Other models leak differently; destination leaks most famously.
Common questions
How do we check which model we use?
Presence of transfer_data[destination] on charges = destination. Absence with platform-created transfers = separate. Charges created on connected accounts = direct.
Should we switch models?
Rarely for leakage reasons — fixing reconciliation is bounded engineering; switching cascades through statements, tax, disputes and support. FG-17 covers the trade-offs properly.