In Module 1 we drew the line between moving a merchant's money and moving your own. This module picks up the next decision: once funds land, do they pool in one account under your control, or do they fan out to each seller at the moment of capture? That single choice sets your cash flow, your float economics, and the shape of your liability. It is worth getting right before you write any code, because reversing it later means re-papering acquirer agreements and rebuilding your ledger.
The two models, defined precisely
Both models start the same way. A buyer pays, the card network clears, and an acquirer settles net proceeds into an account. What differs is where that account is and how funds leave it.
In aggregated settlement, all proceeds land in a single account the platform controls, usually a pooled or "for benefit of" account. The platform then disburses to sellers on its own schedule, net of fees and commission. The acquirer sees one entity receiving funds: you.
In split settlement, the transaction is divided at or near capture, and each party's share is routed toward its own destination. The platform's commission is carved off, and the seller's portion is directed to the seller's balance or bank. Funds spend less time, sometimes no time, pooled under platform control.
The labels vary by provider. Stripe Connect, for instance, frames the same fork as destination charges and separate charges-and-transfers on one side versus direct charges on the other, but the underlying question is identical: whose balance does the money touch, and for how long.
Cash flow and float
The practical difference is timing, and timing is money.
Aggregated: you hold the float
Under aggregation, the acquirer typically funds your pooled account on a T+1 to T+2 basis. You then pay sellers on your own cadence, often weekly or on a rolling delay. The gap between when you receive funds and when you release them is float, and during that window the cash sits on a balance you control.
That float has real value. A platform processing $10 million a month with a seven-day average payout delay carries roughly $2.3 million in seller funds at any given moment. Whether you can earn yield on that balance, or even touch it, depends on how the account is structured and on the regulatory regime you operate under, which we cover in Module 8. Treat held seller funds as a liability you owe, not as working capital, unless your legal structure explicitly permits otherwise.
Split: sellers hold the float
Under splitting, funds reach the seller faster, sometimes same-day, and the platform's float shrinks accordingly. You give up the balance and the optionality that comes with it. In exchange you reduce the operational burden of running payouts and the compliance weight of holding other people's money at scale.
The trade is rarely cosmetic. If your model depends on float yield or on netting seller debts against incoming volume, splitting removes the lever. If your model depends on being a thin, low-liability rail, splitting is the cleaner fit.
Liability: who eats the reversal
This is where the models stop being a matter of preference. A chargeback or refund arrives days or weeks after capture, and the money to cover it has to come from somewhere.
In an aggregated model, the platform is the entity the acquirer funded, so the platform is on the hook. If you operate as a payment facilitator, the liability chain is explicit: a sub-merchant chargeback flows first to the sub-merchant, then to you, then to the acquirer as ultimate backstop. If a seller cannot fund the reversal, you cover it. This is the reason reserves exist, and why most aggregating platforms hold back a percentage or a rolling balance against refunds, chargebacks, and ACH returns.
Splitting does not erase this. With Stripe's separate charges and transfers, the platform's balance is still debited for fees, refunds, and disputes, because the network applies the negative to wherever the original charge was made. Worse, if you have already transferred the seller's share out and the seller's balance is empty, you are short the money and must claw it back manually. Stripe does not automatically reverse a transfer when an associated asynchronous payment later fails, so the platform's balance absorbs the gap until you recover it.
The lesson: faster payouts move liability timing against you. The sooner money leaves your control, the harder it is to recover when a transaction unwinds.
A worked example
Take a marketplace seller who makes a $1,000 sale on which you charge a 10 percent commission. Buyer pays, the sale captures cleanly.
Under aggregation, the acquirer funds your pooled account with the net proceeds on T+1. You hold $1,000, owe the seller $900, and keep $100. You pay the seller on Friday. If the buyer disputes the charge on day 12, you still hold reserve and future volume to net against, and you debit the seller's next payout to recover the $900.
Under splitting with separate transfers, you capture $1,000, keep $100, and transfer $900 to the seller's balance on day one. The seller withdraws it on day two. On day 12 the dispute lands, your platform balance is debited $900, and the seller's balance is zero. You are now chasing a seller for funds you already released. The seller got their money four days sooner. You inherited the recovery problem.
Same sale. The only thing that changed was where the money sat between capture and reversal.
The takeaway
Aggregated settlement concentrates funds, float, and liability on the platform. Split settlement disperses funds and float to sellers but leaves the platform exposed at reversal time unless reserves and clawback logic are built in from the start. Neither is safer in the abstract. The right model follows from whether you want to be a balance-holding operator with float economics and heavy compliance, or a thin rail that moves money quickly and prices reversal risk into reserves. Decide that first. The merchant-of-record question in Module 3 and the ledger design in Module 5 both inherit whatever you choose here.