Marketplace payment splitting is the mechanism that decides who actually receives the money after a buyer pays: the platform, the vendor, and any third party (a referral partner, a payment processor’s fee) with a claim on that transaction. It sounds like a detail until you’re the one architecting it, at which point marketplace payment splitting becomes one of the few decisions that’s genuinely expensive to change later, because it touches accounting, compliance, vendor trust, and refund handling all at once. This is a practical trace through how marketplace payment splitting actually works, the three common models, and where teams tend to get it wrong.
Splitting is not the same thing as paying out
These two get conflated constantly. Splitting is the decision about how much of a given transaction belongs to whom, made at the moment of sale. Payout is the separate, later event of actually moving that vendor’s accumulated balance into their bank account, usually on a schedule (daily, weekly) rather than per transaction. A marketplace can split correctly and still have a broken payout process, or vice versa. Marketplace payment splitting specifically refers to the first part: the allocation, not the transfer.
Three models for moving the money
Model 1: platform collects, then pays out separately
The buyer pays the platform’s merchant account in full. The platform later calculates each vendor’s share and initiates a separate payout, on its own schedule, from its own funds. This gives the platform the most control (and the most bookkeeping burden), since it’s technically holding vendor funds until payout, a structure that in many jurisdictions triggers money transmitter or payment institution licensing requirements.
Model 2: split at the processor (Stripe Connect and equivalents)
The payment processor itself divides the transaction at the moment of payment, routing the vendor’s share directly to a connected account the vendor controls, and the platform’s commission to the platform’s own account. Stripe Connect is the most common implementation of this model. It substantially reduces the platform’s regulatory and custody burden, since vendor funds move to the vendor’s connected account automatically rather than sitting in the platform’s balance, but it does mean adopting the processor’s specific account and onboarding model for every vendor.
Model 3: hybrid, with delayed settlement
A blend of the two: funds are divided at the processor as in Model 2, but a portion is held back for a defined period (common in marketplaces with returns, disputes, or service delivery windows) before being released to the vendor. This adds complexity but protects the platform against issuing a payout for a transaction that gets refunded or disputed shortly after.
Tracing a transaction end to end
A buyer purchase for $100, with a 15% platform commission, moves through the split roughly like this: the processor authorizes and captures $100 from the buyer. Processor fees (typically a percentage plus a fixed amount) come off the top before anything else is calculated. The remaining amount is split: $15 (minus the vendor’s proportional share of the processor fee, depending on how splitting is configured) to the platform as commission, and the balance to the vendor’s connected account or internal ledger balance. That vendor balance then moves to their bank account on the next scheduled payout, not immediately.
Refunds complicate marketplace payment splitting more than anything else
A full refund needs to reverse the split, not just the buyer charge: pulling the commission back from the platform and the vendor’s share back from wherever it settled, which is straightforward if the vendor’s payout hasn’t happened yet and considerably harder if it has. Partial refunds are worse, since they require deciding whether the platform’s commission is refunded proportionally or absorbed entirely by the vendor, a policy decision that needs to be made explicitly rather than left to whatever the payment processor defaults to.
Commission models and the architecture they demand
- Flat percentage: the simplest split to implement, works with any of the three models above.
- Tiered by volume or category: requires the splitting logic to look up a rate at transaction time rather than apply a single stored constant.
- Multi-party splits (platform, vendor, referral partner): needs a model that supports more than two parties per transaction, which not every payment processor’s native splitting feature handles cleanly.
- Subscription or recurring commission: requires marketplace payment splitting logic to run on every recurring charge, not just the initial one, which is easy to miss in an initial build.
The more of these that apply, the more the architecture underneath marketplace payment splitting needs to be a real, tested ledger rather than a set of conditional statements bolted onto the checkout flow. We cover the broader multi-vendor data model this sits on top of in Medusa.js multi-vendor setup: an architecture overview.
Reconciliation is the part of marketplace payment splitting that tends to get underbuilt in an initial launch. Every processor fee, commission amount, and vendor payout needs to tie back to a specific order, both for the platform’s own accounting and for vendors who will, reasonably, ask why a payout doesn’t match what they expected. Building a ledger that records the split at the moment of transaction, rather than recalculating it after the fact from raw processor data, saves considerable pain during a dispute or an audit.
Currency adds another layer once a marketplace operates across more than one country. If the buyer pays in one currency and the vendor is paid out in another, the exchange rate used, and when it’s locked in, becomes part of the split calculation itself. Getting this wrong doesn’t just create a rounding error; it can leave the platform’s commission short or over by a meaningful amount at scale, which is why currency conversion timing deserves its own explicit decision rather than being left to whatever the processor does by default.
The compliance line that’s easy to miss
Depending on the model chosen and where the marketplace operates, holding and moving vendor funds can bring the platform inside the scope of payment services regulation, not just tax reporting. In Singapore specifically, this falls under the Payment Services Act, and the split-at-processor model (Model 2) is generally the path that keeps a marketplace furthest from needing its own payment institution license, since it avoids the platform custodying vendor funds directly. This is not a substitute for legal advice on your specific structure, but it’s the first question worth raising with counsel. We go into the broader compliance and payment-rail landscape for Singapore marketplaces in how to build a marketplace in Singapore.
Testing the split logic deserves the same rigor as testing checkout itself, arguably more, since a bug here means real money going to the wrong party rather than a broken page. A reasonable test suite covers a standard transaction, a full refund before payout, a full refund after payout, a partial refund, a multi-party split if applicable, and at least one currency-conversion case if the marketplace operates internationally. Skipping this and discovering the gap in production, with a vendor’s real payout on the line, is a considerably more expensive way to find the same bug.
How this fits the rest of the architecture
Marketplace payment splitting doesn’t sit in isolation. It depends on how vendor accounts and commission rates are modeled in your core marketplace architecture, and it interacts directly with refund policy and vendor payout scheduling elsewhere in the system. If you’re still working through what marketplace architecture components need to exist before payment splitting logic can be layered on top, that’s covered in our marketplace architecture components piece; treat marketplace payment splitting as one layer of a larger system rather than a standalone integration.
It’s worth planning payout cadence alongside the split model rather than after it. A vendor who sees funds appear in their connected account instantly, but doesn’t actually receive a bank transfer for another seven days, tends to file a support ticket asking where their money is. Being explicit in the vendor-facing UI about the difference between “available balance” and “next payout date” heads off a meaningful share of vendor support volume that has nothing to do with a bug and everything to do with unclear expectations.
Frequently asked questions
Which model of marketplace payment splitting should a new marketplace start with?
For most new marketplaces, split-at-processor (Model 2, such as Stripe Connect) is the sensible default: it minimizes the platform’s custody of vendor funds and regulatory exposure while still being straightforward to implement.
Does marketplace payment splitting handle taxes automatically?
No. Splitting allocates the transaction between parties; tax calculation, collection, and vendor tax reporting are separate systems that need to be integrated alongside it, not assumed to come for free with a splitting model.
How do chargebacks affect marketplace payment splitting?
A chargeback reverses the transaction after funds may have already been split and paid out, so the platform needs a policy (and technical process) for recovering the vendor’s share of a charged-back transaction, which is harder after payout than before it.
Can marketplace payment splitting logic change after launch?
Yes, but it’s disruptive. Changing the commission model or splitting logic after vendors have built expectations around payout timing and amounts needs clear communication and, often, a grace period, rather than a silent change.