Multi-party payment
A multi-party payment is a single incoming payment that has to be divided among several recipients at once — multiple sellers, partners and the platform.
A multi-party payment is a single payment from a buyer that is divided among several recipients at once: two or more sellers, referral partners, contractors and the platform’s own fee, each getting their exact share from the one transaction. The buyer pays once; behind that charge the money is distributed to every party that earned part of it.
How multi-party payment distribution works
- One payment comes in. The buyer pays once, for a basket, a booking or a job.
- A split rule divides it. Each line of the rule names a recipient and an allocation: a percentage or a fixed amount.
- Each share is held or paid out. Every recipient’s share lands on their balance, then goes out on their payout schedule, in their own currency.
- Every leg is recorded against the original payment. That’s what lets the books reconcile.
It’s the harder end of splitting: not just “platform keeps a fee, seller gets the rest”, but three, five or ten parties settled from one payment.
A worked example
A $300 basket with items from three sellers and a 10% platform commission:
| Recipient | Rule line | Amount | Paid in |
|---|---|---|---|
| Your platform | 10% | $30 | USD |
| Seller A (Poland) | Their items, minus commission | $90 | EUR |
| Seller B (Portugal) | Their items, minus commission | $108 | EUR |
| Seller C (US) | Their items, minus commission | $72 | USD |
| Total | $300 |
One charge on the buyer’s card becomes four payments, in two currencies, over at least two rails.
Multi-party payment vs split payment
| Split payment | Multi-party payment | |
|---|---|---|
| Recipients | Two: the platform and one seller | Three or more |
| Typical case | A single-seller order | A multi-seller basket, a job with subcontractors, a sale with a referral partner |
| In Stripe Connect | A destination charge | Separate charges and transfers |
| Hard part | Getting the fee right | Routing each payout, then reconciling every leg to one order |
How multi-party payments are reported across all parties
Each party should see its own share, and the platform should see every leg tied to the original payment. In practice that means:
- one record for the incoming payment
- one line per recipient, with the rule that set it
- one payout per recipient, carrying the payment reference
Without that link, a settlement report is a list of outgoing transfers with no obvious connection to the orders they belong to.
Why it matters
Most payment tools are built around a single split: the platform and one seller. Real marketplaces are messier. A sale might owe a seller, a referral partner, a fulfilment contractor and the platform all at once.
In Stripe Connect, that case needs separate charges and transfers, which Stripe describes as requiring “a more complex Connect integration” (Stripe, charge types). Rebuilding the split by hand is slow and error-prone, and it’s exactly where money goes missing.
How Fynex does it
Fynex splits one payment across many parties in a single run, each in their own currency, by a standing rule or per transaction. Each payout goes over the cheapest compliant rail for that recipient, and every share stays traceable back to your books in Xero or QuickBooks. This is where Fynex goes beyond a single-commission model like Stripe Connect. See multi-party payments from one checkout and split payments for platforms.