How Split Payments Work for Marketplaces From Checkout to Payout

Split payments for marketplaces work like this: the customer pays once, the platform's payment account collects the full amount, and a set of rules divides it between the seller, the platform and anyone else owed a share, then pays each party on its own schedule.

That one sentence hides most of the hard parts. Who owns the money between checkout and payout? What happens to the processing fee? Which party absorbs the rounding cent? What do you do when a refund arrives three weeks later, after the seller has already been paid? This guide walks through the whole path of a single marketplace payment, from the moment the card is charged to the moment each party sees money in the bank, using one worked example the whole way through.

The example we will follow

A customer books a home renovation job on a services marketplace and pays 1,000 USD. Four parties have a claim on that payment:

• Provider, the contractor who does the work, receives 70 percent.
• Platform, the marketplace itself, keeps 15 percent as its commission.
• Partner, the referral partner who sent the customer, earns 10 percent.
• Subcontractor, a specialist the provider brought in, gets 5 percent.

On paper this is simple arithmetic. In production it touches five separate systems: checkout, the payment operator, your rules, your ledger and the payout rail. Let's take them in order.

Step one is the charge on your platform account

The customer's card is charged by a licensed payment operator, on your platform's account with that operator. This matters for compliance. The operator is the regulated party that moves money and holds it in a protected balance. Your marketplace instructs the operator where money should go. Keeping funds inside the operator's system and paying sellers through its connected accounts model is the usual way platforms avoid handling customer money themselves. The exact licensing picture depends on your country and business model, so confirm it with your own counsel.

Most operators offer two broad ways to split a charge for a marketplace:

• Destination style charges, where a single connected seller account is named at checkout and the platform keeps an application fee. Good for one seller per order, awkward once three or four parties share the payment.
• Separate charges and transfers, where the platform collects the full amount and then creates transfers to as many connected accounts as needed. This is the model that supports real multi-party splits, and it is the one we will use here.

With separate charges and transfers, the 1,000 USD lands on the platform balance first. Nothing has been split yet. That gap between the charge and the transfers is where your rules engine does its work, and it is also where most homegrown implementations get messy. If you are comparing approaches, our page on marketplace payments goes deeper into the trade offs between the two models.

Step two is applying the split rules

A split rule is a small, versioned piece of configuration that says who gets what. For our example it has four lines, each with a party and a percentage. Real rules usually need a few more decisions:

• Percent or fixed. A partner might earn a flat 25 USD per booking instead of 10 percent. Fixed lines are applied first, then percentages are taken from what is left, or from the gross, depending on how your contracts read.
• Who absorbs the processing fee. If the operator charges, say, 30 USD on this payment, does the platform swallow it, or is it deducted from every share proportionally? Write this down per rule. Most disputes with sellers start right here.
• Rounding and remainders. Split 99.99 USD three ways and you will have a cent left over. Pick one party to receive remainders (usually the platform) and apply that consistently.
• Priority. When more than one rule could match a payment (a product rule and a default rule, for example), the engine needs a clear order of precedence.
• Holds. Many marketplaces hold the provider's share until the job is delivered or a return window closes. A hold changes when money is paid, not how much.

The rule produces an allocation: one line per party with an amount. That allocation is the thing you want to store, sign and never change after the fact. If a rule is edited next month, past payments keep the version that applied when they were split. This is the core of what a split payment API should give you out of the box, rather than something every engineering team rebuilds.

Step three is writing the ledger

Before any money moves to sellers, the split should be recorded in a double-entry ledger. Every allocation becomes a set of balanced entries: the platform's clearing account is debited 1,000 USD and four payable accounts are credited 700, 150, 100 and 50 USD. Debits equal credits, always.

Why bother with double entry instead of a simple table of who is owed what? Three reasons.

1. Balances you can trust. A seller's balance is the sum of their entries, not a number someone updated in place. You can rebuild it from history at any time.
2. Refunds and reversals become ordinary entries. A refund is just more entries in the opposite direction, linked to the original split. Nothing is overwritten.
3. Reconciliation has something to match. Your finance team can compare the ledger with the operator's balance transactions line by line. Without a ledger, reconciliation means comparing a bank statement against a spreadsheet and hoping.

Step four is paying each party

Payouts are usually a separate event from the split. The split says who is owed what; the payout schedule says when that balance leaves the platform. In our example:

• The provider is paid weekly, but only after the job is marked complete, because the rule holds the 700 USD until delivery.
• The subcontractor is paid on the same weekly schedule, with no hold.
• The referral partner is paid monthly, and only when their balance passes a 50 USD minimum, to avoid dozens of tiny transfers.
• The platform's 150 USD stays on the platform balance and is paid out to the company bank account on the operator's normal schedule.

Each payout is another set of ledger entries: the party's payable account is debited and a cash in transit account is credited, until the operator confirms the transfer. We cover the choice between weekly, monthly and on demand schedules in detail in our guide to vendor payout schedules, and the product side lives on the marketplace payouts page.

What breaks first in homegrown split payments

Most marketplaces start with a single transfer per order and a commission percentage hard coded somewhere in the checkout controller. That works until one of these shows up:

• A second recipient. The first referral partner or subcontractor turns a one line transfer into a loop, and the loop needs rounding rules.
• The first partial refund. Suddenly you need to know how much each party received and claw back the right fraction from each. See our walkthrough of proportional refunds in a split payment.
• The first month end close. Finance asks why the operator balance and your internal numbers differ by a few hundred dollars, and nobody can say which payments caused it.
• Tax season. You need yearly earnings per seller, and the only source is a list of transfers with no link back to the original payments.

None of these are exotic. They are what happens in the first year of almost any marketplace that grows beyond a handful of sellers.

A checklist before you build or buy

Whether you build split payments in house or use a layer like FractionalPay on top of your own operator account, check that you can answer yes to each of these:

• Can one payment be split between more than two parties, with percent and fixed lines mixed?
• Is the rule version stored with every split, so editing a rule never changes history?
• Is there a written decision on fees, rounding and remainders?
• Does every split, refund and payout produce balanced ledger entries?
• Can a refund be reversed proportionally across all parties, including those already paid?
• Can each party have its own payout schedule, hold period and minimum threshold?
• Can finance reconcile the ledger against the operator's balance daily?

If your marketplace is at the stage where these questions keep coming up, the marketplace use case shows how FractionalPay handles each one on top of your existing payment account, without holding funds and without a cut of your transactions. You can also try the 1,000 USD example above in the split simulator on the home page and see the ledger lines it produces.