Most marketplaces pick their charge type in an afternoon. It is usually the first real architecture decision in the build, it gets made from a docs page, and it is the one that costs the most to reverse once sellers are onboarded and money is moving.
Here is the version I wish more teams had before they started.
The fork
Stripe Connect gives you three ways to move money when a buyer pays a seller on your platform.
Direct charges put the charge on the connected account. The seller is the merchant of record. Your platform takes its cut as an application_fee_amount. The seller’s name is on the statement descriptor, and the seller’s Stripe account carries the dispute.
Destination charges put the charge on your platform account and transfer funds onward to the seller. Your platform is the merchant of record. You own the customer relationship, the statement descriptor and — this is the part people skim — the dispute.
Separate charges and transfers decouple the two entirely, which is what you need when one payment splits across several sellers, or when the money has to sit before it moves.
Teams usually choose destination charges. It feels like the platform-centric option: you control the checkout, you see everything in one dashboard, the integration is simpler. All true.
What destination charges actually commit you to
Three things, none of which show up in a demo.
You own every dispute. With destination charges the chargeback lands on your platform account, and the funds come out of your balance. You can set on_behalf_of and you can claw back from the seller with a reversal, but the acquirer’s relationship is with you. If your sellers are in a category that attracts disputes, your platform’s dispute ratio is the one that gets flagged — not theirs. A marketplace with a thousand well-behaved sellers and twenty bad ones has one dispute ratio, and it belongs to the platform.
You inherit their risk profile. Underwriting looks at the aggregate. Onboarding a category you did not plan for changes the risk picture of the whole platform, and you find out at the worst moment.
You are bound by the corridor. This is the one that bites hardest.
The corridor problem
Stripe restricts which country pairs can move money. A platform account in one country cannot freely transfer to connected accounts everywhere; cross-border payout support is specific, and it changes.
If your platform is incorporated in one country and your sellers are spread across many, destination charges mean every payout has to survive your platform country to seller country. The pairs that are not supported do not fail loudly at integration time. They fail when you onboard your first seller in that country, months in, with a signed agreement and an onboarding email already sent.
Direct charges with Standard accounts sidestep this. The seller holds their own Stripe account in their own country, under their own entity, with their own payout rails. Your platform is not in the funds-flow path at all for the settlement leg — you are taking an application fee off a charge that lives on their account.
So the rule of thumb I use: the more geographically distributed and independent your sellers, the more direct charges with Standard accounts look right, and the more a destination-charge design is quietly accumulating a problem that surfaces during expansion.
What you give up with direct charges
Plenty, and it is worth being honest about it.
The seller’s name goes on the statement descriptor, not yours — which for a consumer marketplace can mean more “I don’t recognise this charge” disputes, not fewer. You lose the single-dashboard view. Refund and dispute handling moves to the seller, which is good for liability and bad for consistency, because your support team now depends on a third party to resolve a customer’s problem. Onboarding is heavier: a Standard account means the seller completes Stripe’s own onboarding rather than a few fields in your flow, and some will not finish it.
For a platform whose sellers are small, domestic, and would struggle with Stripe onboarding, destination charges are the better trade. That is a real answer, not a consolation prize.
The questions that actually decide it
Before writing any integration code:
- Where is your platform entity incorporated, and where will your sellers be in two years? Not today — two years. The corridor question is about where you are going.
- Who should appear on the cardholder’s statement? This drives both dispute volume and brand.
- Who can absorb a dispute? If the honest answer is “not our sellers”, you are choosing destination charges and you should budget for the losses rather than discover them.
- Does one payment ever split across more than one seller, or does money ever need to be held before release? If yes, separate charges and transfers, and plan the hold mechanism deliberately rather than custodying funds by accident.
- What happens on a partial refund? Work the full path — refund, application fee refund, transfer reversal — on paper before you build. This is where most reconciliation bugs are born.
The part that is hard to undo
Changing charge type after launch is not a code change. It is a re-onboarding of every connected account, a migration of payout configuration, a change to who holds dispute liability, and in most cases a change to the contracts you have with your sellers. Teams do it, but it is a quarter of work and a lot of seller churn.
An afternoon of thinking about corridors and disputes at the start is worth more than any other hour you will spend on Connect.