September 24, 2026 · Muhammad Umar · More by Muhammad Umar
Destination Charges vs. Separate Transfers in Stripe
Marketplace builders on Stripe Connect must choose between destination charges and separate charges and transfers. Here's Stripe's own decision criteria.
Any team scoping a multi-vendor marketplace or creator-payout platform on Stripe Connect runs into the same fork early: destination charges, or separate charges and transfers. Both are "indirect" charge types — the payment lands on the platform's Stripe account first, not the connected account's — and they're easy to confuse because the difference isn't obvious from either name. Stripe's own documentation lays out a specific, narrow set of criteria for choosing between them, and getting it wrong means rebuilding your payment flow later.
The decision criteria, verbatim from Stripe
Stripe frames this as a two-way fork, and marketplaces choose almost exclusively between these two (a third type, direct charges, fits a different shape of business — connected accounts that transact directly with their own customers, largely unaware the platform exists, like a SaaS platform enabling invoice payments).
Use destination charges when customers transact with your platform for products or services that connected accounts provide, and each transaction involves exactly one connected account and one customer. Stripe's own examples: a branded service built on independent contractors, like a rideshare app, or a business-services marketplace matching contractors with homeowners.
Use separate charges and transfers when a single transaction needs to split funds across multiple connected accounts, or when you need to create the charge before you even know which connected account will receive the funds, or before you're able to transfer them. Stripe's cited example is DoorDash-shaped: a single cart or order that has to divide payment across more than one party.
Where the two mechanically diverge
With a destination charge, you create one charge on your platform, and a portion of the funds transfers to the connected account's balance immediately, as part of that same charge. With separate charges and transfers, the charge and the transfer are two distinct steps: you create the charge on your platform first, then create a separate transfer (or transfers) to move funds out to one or more connected accounts — which is what makes it possible to split a single payment or defer the transfer entirely.
That structural difference is also why Stripe describes separate charges and transfers as the more complex integration to build, and recommends using it only when the use case actually calls for it — a one-to-many or many-to-one payment split, a charge created before the destination account is known, or a transfer that needs to happen before or independently of the underlying payment.
Refunds behave differently, too
The two charge types also diverge sharply on refunds. On a destination charge, if refunding also requires reversing the transfer already made to the connected account, and that account's balance is now insufficient to cover the reversal, the refund request fails outright — it doesn't get created as a pending refund, it simply errors. With separate charges and transfers, the charge and the transfer are decoupled: Stripe debits your platform balance for the refund directly, and you separately reverse the transfers to your connected accounts to recover that cost, using tools like transfer_group and source_transaction to manage the bookkeeping yourself.
One thing that doesn't change based on which you pick: in both indirect charge types, Stripe debits refunds, chargebacks, and its own fees from the platform's balance, not the connected account's. Whichever charge type a marketplace uses, the platform is the one carrying that financial risk.
Why this is worth deciding early
A two-sided marketplace or creator-payout platform doesn't have the same payment shape as a single-seller storefront, and that's exactly the kind of thing this decision forces a team to confront before writing checkout code rather than after. If your transactions are cleanly one connected account to one customer, destination charges get you there with less integration work. The moment a single purchase has to be split across multiple sellers or creators, or a charge has to exist before you know who's getting paid, separate charges and transfers is the only one of the two that actually supports it.