How to split payments with Stripe Connect — and where it falls short

If you run a marketplace on Stripe, “split the payment” almost always means Stripe Connect. Connect is the most mature marketplace-payments product on the market, and it models the common case cleanly: one customer pays, one seller gets paid, and you keep a cut. This is a practical guide to how that split actually works in Connect — the charge types, the application fee, the on_behalf_of question — and then the honest read on where Connect starts to strain. If you want the concept first, we cover what a marketplace split payment even is separately; this piece is about doing it in Connect.

How a split works in Stripe Connect

A split in Connect is a charge plus a transfer plus an application fee — you take the customer’s money, forward a share to a connected account, and keep your cut. Stripe gives you three shapes to arrange that, and the one you pick decides where the charge lands and how the fee is collected.

• Direct charges. The charge is created directly on the connected account. The seller is the merchant of record for that payment, Stripe’s processing fee comes off their balance, and your platform takes its cut as an application_fee_amount. This is the lightest-touch model — good when the seller genuinely owns the customer relationship.
• Destination charges. The charge lands on your platform account, and you set transfer_data.destination to the connected account. Stripe immediately moves the seller’s share to them and leaves your fee on your balance. You can also set on_behalf_of to make the connected account the business of record — which matters when your platform and the seller sit in different regions, because it settles the charge in the seller’s country and uses their fee structure and statement descriptor.
• Separate charges and transfers. You take the charge on your platform first, then call transfers.create for each connected account whenever you’re ready. You tie each transfer back to the originating charge via source_transaction (and group them with a transfer_group), so the payout waits until the charge’s funds are available and stays linked to the sale.

The application fee is the mechanism that keeps your commission. On a destination charge you either set an explicit application_fee_amount or let the fee fall out of the difference between the charge and the transfer amount; on a direct charge the application_fee_amount routes your cut back to the platform. Either way, the pattern is the same shape as any split rule: the whole payment, minus your line, to the seller.

For a single seller per payment, this is clean and well-trodden — including for operator businesses; we walk through it for Connect payouts in home services specifically.

Where Stripe Connect runs out

Connect is genuinely good at the shape it models. Marketplaces tend to hit its edges in the same four places.

Multi-party fan-out. The moment one payment has to become several payouts — a basket spanning three sellers, a booking that pays a venue and a service provider and you — you’re into separate charges and transfers, creating and tracking one transfer per recipient against the same charge. It works. But the transfers linked to a charge can’t exceed the charge amount, each one waits on the charge’s funds becoming available, and you’re the one assembling the fan-out and reconciling every leg back to the sale. Stripe hands you the primitives; the orchestration is yours.

Richer-than-flat fee logic. An application_fee_amount is a single number per charge. Real commission is often more than that: tiered rates by seller, a fixed listing fee plus a percentage, a cap, a minimum, a referrer’s override taken before the seller’s share. You can express all of it — by computing the right amounts in your own code and passing them in. The logic lives in your application, not in a rule you can state once and reuse.

Leaving Stripe’s rails. Connect settles on Stripe. That’s the model, and it’s transparent — but it means the payout to a seller in another country goes the Stripe way, not necessarily the cheapest compliant way. When a local scheme, a faster-payment rail, or a stablecoin corridor would land the money quicker and for a fraction of a cross-border wire, Connect doesn’t give you that choice, because the rail question always resolves to “Stripe.” Over thousands of multi-currency payouts, that’s not a rounding error — it’s margin.

Funds move on Stripe’s clock. A charge sits in a pending balance before it’s available (commonly a rolling two days), and a transfer using source_transaction won’t execute until then. Add reserves and review holds — settlement can be paused while risk clears, sometimes for extended windows — and the timing of your sellers’ money is partly outside your control. We go deeper on the hold mechanics in the Stripe vs Fynex breakdown. None of this is Stripe being careless; it’s the shape of a processor that holds the funds it settles.

Where Fynex fits

Fynex isn’t a replacement for card acceptance — keep Connect for what it’s good at. It’s the layer that takes over once the split has to fan out to several parties, price on real commission logic, and pay out over whatever rail is genuinely cheapest.

You define a split rule as a set of lines: each line is a percentage or a fixed amount, paid to a named payee. Assign a rule to a seller or to a single transaction, and the commission breakdown is shown before anything moves — no computing fee amounts in application code and hoping the arithmetic reconciles later. Where an application_fee_amount is one number, a rule is the whole allocation, stated once and reused on every matching payment.

Then the payouts. Each recipient’s leg is routed over the genuinely cheapest compliant rail — a local rail or faster payment or stablecoin instead of a default SWIFT wire — and every payout leg is reconciled back to the originating payment and booked into Xero or QuickBooks. Because Fynex owns no rail and earns no spread on your flow, the routing decision is neutral: it picks the cheapest path, not the one that pays Fynex. Anything that actually moves money holds for human approval first.

That’s the division of labour. Stripe accepts the payment. Fynex handles the multi-party split, the rail-optimised payout, and the reconciliation on top — as an FCA-authorised e-money institution with client funds safeguarded, PCI DSS Level 1, and able to act as Merchant of Record where you want that liability off your books.

So which should you use?

Use Stripe Connect when the split is the shape it’s built for: one payment, one connected seller, a flat platform fee, sellers you’re happy to pay on Stripe’s rails and Stripe’s clock. It’s mature, well-documented, and hard to beat at that job — and you should keep it doing that job.

Add Fynex when the split outgrows a single application fee: a payment that fans out to several payees, commission that’s more than a flat percentage, payouts that would be cheaper off Stripe’s rails, and reconciliation you’d rather not do by hand every month-end. You don’t rip out Connect — you keep it as a pay-in rail and put a layer on top that treats multi-party splitting and rail-optimised payouts as the default, not the workaround.

The honest read: Connect gives you excellent primitives to build a split. Fynex runs the split — rule, payout and reconciliation — so one customer pays once, everyone owed gets paid correctly on the cheapest path, and the books are already reconciled. Accounts hold money. Rails move it. Fynex is the layer that thinks.