--- title: "Multi-party payments: paying several sellers from one checkout" description: "How one checkout splits the platform fee and each seller's payout automatically: Stripe Connect vs Fynex vs Adyen, the costs, and where it breaks." url: "/blog/multi-party-payments-single-checkout/" date: "2026-07-30" updated: "2026-09-30" author: "Valeria Vahorovska" tags: ["Guides","Split Payments"] --- Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “Multi-party payments: paying several sellers from one checkout”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks. # Multi-party payments: paying several sellers from one checkout **A multi-party payment is one checkout that pays several parties: your platform's commission and each seller's share, split automatically by rule.** The customer pays once. Behind that charge, the payment divides into several payouts, often in different currencies and over different rails, and every leg has to reconcile back to the one order. A customer fills one basket. Inside it: a lamp from a seller in Poland, a rug from a seller in Portugal, a set of prints from a seller two towns over. They check out once, pay once, see one line on their card statement. Behind that single payment, three sellers are owed three different amounts, in two different currencies, plus your commission carved out of each — and none of them get paid until you've divided one number into four and moved each piece to the right place. That's multi-party payments: one checkout, one charge, many recipients. It looks like a rounding exercise and turns into the hardest plumbing a marketplace owns. Here's what actually makes it hard, how a multi-party split is modelled, and where the standard tooling runs out. ## What makes multi-party hard The moment a payment has more than one owner, three problems show up at once — and they compound. - **Fan-out.** A two-sided split (your fee, one seller) is tidy. Multi-party fans one payment into three, five, ten payouts, each on its own rule. A basket across three sellers isn't three separate sales you can process independently — it's one settled payment you have to divide, so a mistake on any line is a mistake on the whole order. - **Different currencies and countries.** The Poland seller wants euros; the local one wants dollars. One payment now has to become payouts denominated differently, each subject to its own FX conversion and its own compliance checks. The customer's single charge hides a small pile of cross-border movements. - **Different rails.** The cheapest way to reach a seller in Portugal is not the cheapest way to reach one down the road. A domestic faster-payment scheme, a SEPA transfer, a local rail, sometimes a stablecoin corridor where a wire would eat the seller's margin — each recipient has a genuinely different best route, and forcing them all down one default pipe overpays on most of them. - **Reconciliation.** This is the one that bites at month-end. Every payout leg — each seller, each commission line, each partner cut — has to be matched back to the single sale that created it. Miss that and a settlement report becomes a pile of outgoing transfers with no obvious link to the order they belong to, and someone spends a day rebuilding the trail by hand. None of these is hard in isolation. The difficulty is that they land together, on every multi-party payment, forever. ## How a multi-party split is modelled The clean way to model a fan-out is a **rule made of lines**. Each line names one recipient and one allocation — a **percentage** or a **fixed amount** — and the rule is the set of lines that together account for the whole payment. You attach the rule to a seller or to a specific transaction, and every payment it touches divides the same way, automatically, without a developer in the loop. A basket across three sellers with a 10% platform commission reads as one rule with four lines: ``` 💰 Customer pays: $300 ├── 🏢 Your commission: $30 (10%) ├── 👤 Seller A (Poland): $90 → EUR payout ├── 👤 Seller B (Portugal): $108 → EUR payout └── 👤 Seller C (local): $72 → USD payout ``` Percentage lines flex with the order size; fixed lines — a flat listing fee, a per-item charge — stay put regardless. Mixing them is normal. The point is that the split is **configuration, not code**: you state the rule once, and the breakdown surfaces *before* anything moves, so you can see exactly who's owed what while it's still checkable. Then comes the half everyone underestimates — the payout. Computing the division is arithmetic; **paying each party** is where money and time leak. Once the funds settle, each line has to become a real transfer to a real seller, and each should take the **genuinely cheapest compliant rail** for that recipient's country and currency, not a single default route. Pick per-recipient, tell each seller which rail it took and when it lands, keep a fallback for when the first choice is unavailable. The pipeline, end to end: ``` One checkout ──▶ One payment ──▶ Split rule applied ──▶ Breakdown shown │ ┌───────────────┬───────────────┼──────────────┐ ▼ ▼ ▼ ▼ Seller A Seller B Seller C Your commission (SEPA, EUR) (SEPA, EUR) (ACH, USD) (your account) │ │ │ │ └───────────────┴───────────────┴──────────────┘ ▼ Every leg reconciled to the original payment ``` The last row is the whole job. A multi-party payment isn't finished when the money leaves — it's finished when every leg is matched back to the sale that created it and posted to your ledger. That's what turns a fan-out from a liability into clean books. ## Checkouts that split the platform fee and vendor payouts automatically **Three kinds of tool split one checkout between your platform and several sellers without manual reconciling: Stripe Connect, a split-and-payout layer such as Fynex, and Adyen for Platforms.** They differ in how many sellers one payment can reach, which rails the payouts take, and whether each leg reconciles back to the order on its own. | | How the split happens | Sellers per payment | Payout rails | Reconciliation to the order | Platform-layer cost | |---|---|---|---|---|---| | **Stripe Connect, separate charges and transfers** | One charge on the platform, then a transfer per seller | Several | Stripe's payouts | You match transfers to the charge | $2 per monthly active account + 0.25% + 25¢ per payout (US) | | **Fynex** | A split rule per seller: percentages and fixed amounts, previewed before money moves | Several | ACH (US) or Faster Payments (UK) per recipient | Every leg posted back to the sale in Xero or QuickBooks | 1.4% per US-card payment + $0.20/auth; payouts 0.5% (min $1) + $100/mo | | **Stripe Connect, destination charges** | One charge, part of it transferred to the seller | One | Stripe's payouts | Per charge | As above | | **Adyen for Platforms** | Split instructions sent at authorization, capture or refund | Several balance accounts | Adyen payouts | Via Adyen's reports | Contract pricing | - **Sources:** Stripe's [charge types](https://docs.stripe.com/connect/charges) say destination charges suit transactions that involve "a single connected account", while separate charges and transfers are for transactions that "involve multiple connected accounts" and "require a more complex Connect integration". The costs are from [Stripe Connect pricing](https://stripe.com/connect/pricing) (the platform-handles-pricing plan) and [Adyen's split transactions docs](https://docs.adyen.com/platforms/online-payments/split-transactions/). - **All costs are on top of card processing.** None of the platform-layer fees above include what the card networks and acquirer charge to accept the payment. **A worked example.** Take a marketplace with 200 active sellers, and $400,000 a month paid in and out through 800 payouts of $500 each. - **Stripe Connect:** 200 × $2 = $400 in account fees, plus 800 × (0.25% × $500 + $0.25) = $1,200 in payout fees. That's **$1,600 a month** in the platform layer. - **Fynex:** no account fee; 800 × (0.5% × $500) = $2,000 in payout fees, plus the $100 payouts plan — **$2,100 a month** in the payout layer. Card acceptance is priced too, at 1.4% per payment on US-issued cards plus $0.20 per authorization, where Stripe bills processing on top of Connect. The [split payment calculator](/split-payment-calculator/) runs the split itself against your own numbers. ## Where Stripe Connect runs out Stripe Connect is the reference point, and it handles the multi-party case directly through its **[separate charges and transfers](https://docs.stripe.com/connect/marketplace/tasks/accept-payment/separate-charges-and-transfers)** model: take one charge on your platform account, then transfer funds to several connected accounts, holding your fee back from what you send. It's the documented pattern for a basket that spans multiple sellers, and inside Stripe's own rails it works. Marketplaces tend to hit its edges in the same three places — [we go deeper in the Stripe Connect breakdown](/blog/fynex-vs-stripe/) — when payouts need to leave Stripe's rails and schedule, when the fee logic grows past a flat percentage into tiers and caps and referrer overrides, or when reconciling many legs across many currencies becomes the actual cost. None of that makes Connect wrong; it means a growing marketplace eventually wants a layer that treats multi-party fan-out and per-recipient payouts as the default, not the special case. ## Where Fynex fits Fynex is built for exactly this shape of money. Fynex isn't a bank and it isn't a rail — it's the **agentic finance layer** that runs the money chain on top of the accounts and rails you already hold. You define a split rule as a set of lines — each a percentage or a fixed amount, to a named payee — and assign it to a seller or a transaction. When a payment lands, Fynex computes the breakdown, shows the commission split before anything moves, **[pays each US seller by ACH and each UK seller by Faster Payments](/features/payouts/)**, and [reconciles every leg back to the original sale into Xero or QuickBooks](/blog/reconcile-payments-to-xero/) automatically. The neutrality is the part that's hard to copy: Fynex owns no rail and earns no spread on your flow, so it optimises *your* cost, not volume on a network that pays Fynex. Sellers outside the US and UK aren't paid out by Fynex today. Around the split sit the rest of the money chain — auto-invoicing, agentic collections chasing what's owed, multi-currency with VAT handled, and cash forecasting across every account and PSP in one view. And it's built the right way up for the job: client funds safeguarded by default with Fondy Ltd, an FCA-authorised EMI (FRN 900705), PCI DSS Level 1, able to act as Merchant of Record. For the deeper mechanics of the rule engine itself, the [split-payments guide](/blog/split-payments-marketplace-explained/) walks the two-party case first. ## The takeaway Multi-party payments are what "split payments" become the day your marketplace stops being two-sided. One checkout, one charge, several sellers in several countries — the arithmetic is trivial and the operations are not, because every extra recipient is another rail to route and another leg to reconcile. The tooling that survives is the tooling that treats fan-out, per-recipient payout and reconciliation as one job, not three afterthoughts. Accounts hold money. Rails move it. Fynex is the layer that thinks — and for a marketplace paying many sellers from one payment, that's the layer that decides whether checkout ends in clean books or a spreadsheet. Related: [how to hold funds in a marketplace](/blog/hold-funds-marketplace-escrow-authhold/) and [delayed capture](/blog/delayed-capture-explained/) cover what happens between the single checkout and the several payouts; [the marketplace payout ledger](/blog/marketplace-payout-ledger/) is the record it all has to reconcile to; and the [split payment calculator](/split-payment-calculator/) prices the split against your own numbers.