Marketplace Payment Operations: The Split-Payment & Connected-Account Runbook

Most marketplace payments content stops at launch — pick Stripe Connect or Adyen for Platforms, wire up onboarding, take your cut. The operator's problem starts the day after. Money is now moving between buyers, your platform, and sellers on every order, and the questions that decide whether you lose money are operational: when do you release a payout, what happens when a refund lands after the seller is paid, who eats a chargeback, and how much do you hold back. This is a day-2 runbook for platforms already live on split payments and connected accounts. For the upstream decision of which account model to run in the first place — PSP, PayFac, marketplace, or merchant of record — see the PSP vs PayFac operations reference; this article assumes that choice is made and the money is already flowing.

The three funds-flow models — and why the choice dictates everything downstream

Every downstream operation — refunds, reserves, disputes, reporting — is determined by one thing: who is merchant of record on each transaction. That is set by your funds-flow model. There are three, and the differences are operational, not cosmetic.

Separate charges and transfers

The platform charges the buyer on its own account, then creates separate transfers to each seller's connected account. The platform holds the money first and controls timing, can split one charge across several sellers, and is merchant of record — which means the platform is liable to the acquirer for disputes and is the entity that must fund refunds. Most control, most concentrated risk. This is the model marketplaces choose when they want to manage seller risk centrally.

Destination charges and on-behalf-of

The charge is created on the platform but routed to a destination connected account automatically, with the platform taking an application fee. Adding on_behalf_of sets the connected account as the settlement merchant for that charge, moving the statement descriptor and more of the dispute exposure to the seller. A middle ground: platform oversight with per-charge, single-seller settlement.

Direct charges and split settlement

The charge is created directly on the seller's connected account — the seller is merchant of record — and the platform takes an application fee. The seller bears card fees and chargeback liability; the platform carries the least risk and the least control. A multi-party split payment, where one buyer payment is divided across the platform, one or more sellers, and sometimes tax or shipping parties at settlement, is the settlement-time expression of this model. Adyen for Platforms and Stripe direct charges both implement variants.

The single sentence to internalize: the merchant-of-record position is not a billing detail, it is the assignment of liability. Read every later section as a consequence of which row you operate.

Seller onboarding and KYB at platform scale

You are underwriting a portfolio, not a single merchant. Onboarding a sub-merchant or connected account means collecting identity, business, and bank details and verifying them before money moves — and the operational lever is capability gating: enable an account to accept charges only when identity verification clears, and withhold payout capability until KYB is complete and bank ownership is confirmed. Tier sellers by risk — a new seller in a future-delivery category starts with longer holds and a reserve; an established seller with clean history earns faster payouts. Re-verification is continuous, not one-time; the monitoring and exit side is ongoing merchant monitoring and KYB offboarding. Capability gating is also your fastest containment tool: when a seller's risk signal spikes, freezing payout capability while leaving charge capability intact stops the bleeding without taking the storefront down.

Payout scheduling, holds, and release

A payout schedule is a risk instrument disguised as a convenience setting. The delay between a sale and a seller payout — T+n — exists to cover the window in which a refund or chargeback can still claw the money back. Default rolling schedules (daily, weekly) work for steady low-risk volume; manual payouts and longer holds are for new sellers, volume spikes, and future-dated goods. The mistake is treating the schedule as fixed.

Decide each payout against an explicit rule, not a timer:

1. Is KYB complete and bank ownership confirmed? If no — hold and request documents.
2. Is the seller's open refund and dispute exposure greater than the pending payout? If yes — hold, or partial-release to cover the exposure.
3. Is volume or refund velocity anomalous against the seller's own baseline? If yes — hold and review.
4. Otherwise — release on schedule.

For the mechanics of a payout that fails after you release it — bad bank details, a closed account, a rail rejection — that is a different runbook: payout and disbursement failure. This section is about whether to release; that one is about why a released payout did not arrive.

Negative seller balances and debit recovery

This is the failure mode that defines marketplace operations, and most platforms under-plan for it. A balance goes negative when a refund or chargeback settles after the seller has already been paid out: the connected account now owes money it no longer holds. Under direct charges that is the seller's problem to the extent the connected account can carry it; under separate and destination charges the platform is merchant of record and therefore the backstop to the acquirer — if the seller cannot cover it and you held no rolling reserve, the platform absorbs the loss.

Recover in order. Skipping straight to write-off forfeits money you could have collected; jumping straight to debiting a seller's bank account without prior authorization creates a dispute of its own.

A worked example. A travel seller is paid out weekly. A customer disputes a $1,200 booking three weeks after payout; the seller's balance is $300. Step 1 nets the $300 plus the next $900 of incoming transfers. If the seller stops selling, step 2 attempts a $900 debit on the authorized account. If that fails and a $600 reserve was held, step 3 recovers $600, leaving $300 for manual collection or write-off. The platform's exposure was capped by a reserve sized to the booking-to-travel window — which is the entire point of reserves.

Reserves for connected accounts

A reserve is the only instrument that caps platform exposure before a loss happens. Three shapes: a rolling reserve holds a portion of volume for a defined window and releases on a rolling basis; a fixed reserve holds a flat amount; a capped reserve accrues until a ceiling. Impose them where the delivery-and-dispute window is real — new sellers without history, future-dated goods (events, travel, pre-orders, custom manufacture), and high-dispute verticals. Size the reserve to that window — the gap between payment and delivery, plus the dispute window — not to a universal percentage, because there isn't one. Release as the window closes and the seller builds history; a reserve that never releases is a seller-retention problem.

Split refunds

A refund on a split payment has to unwind the split. Under separate and destination charges the platform funds the refund and typically reverses the corresponding transfer to claw it back from the seller — and if the seller's balance is short, you are back in the negative-balance waterfall above. Decide in advance whether the platform also refunds its application fee or keeps it. Partial refunds after payout are the common case and the one that most often drives a balance negative. And some refunds are platform-funded by policy — goodwill, platform-caused errors, SLA credits — which the seller should never bear.

Dispute and chargeback liability across buyer, seller, and platform

The dispute is where the funds-flow model's liability assignment becomes real money. Under direct charges the seller is merchant of record and the chargeback is theirs; under separate charges the platform is liable to the acquirer and chooses whether to pass the cost to the seller via a balance debit. But liability and evidence sit in different places: the seller holds the fulfillment proof — tracking, delivery confirmation, communications — while the platform usually owns the dispute interface with the PSP. That handoff is the operational risk. Build an evidence-handoff SLA: the seller must supply representment evidence within a window that beats the network's deadline, or the platform submits with what it has. The representment mechanics are in the chargeback representment guide for merchants, and the evidence standard for the strongest dispute category in the Visa Compelling Evidence 3.0 build guide; this section is about who owns which part when there are three parties instead of one.

Platform reporting and tax obligations

Settlement carries reporting. The entity that settles funds to sellers generally carries the tax-reporting obligation — often the platform under separate and destination charges, often the PSP under direct charges. In the US that is Form 1099-K for sellers above a reporting threshold; the threshold amount and effective tax year have changed repeatedly and been delayed, so platforms should verify the current threshold and effective year rather than hard-code one. In the EU, DAC7 (Council Directive 2021/514) requires digital platform operators to collect and report seller income to tax authorities, with scope and thresholds that vary by member-state transposition. Treat both as obligations to confirm against current guidance per jurisdiction — and make sure onboarding collects the tax identifiers reporting will require, because retrofitting tax IDs onto an existing seller base is far harder than collecting them at onboarding.

Reconciliation at platform scale

A marketplace reconciliation is a three-or-more-way match per transaction: the buyer charge, the application fee, each seller transfer, any reserve hold or release, and the payout batch that settles to the seller's bank — multiplied across the portfolio. Breaks cluster around the moving parts: transfer reversals from refunds, reserve hold-and-release timing, fee adjustments, and cross-currency conversion. The discipline is the same as single-merchant reconciliation but the cardinality is higher; when the platform's books and the PSP's books disagree, work the PSP reconciliation failure runbook with the connected-account dimension added to every match key.

Operator readiness checklist

• Funds-flow model documented, with the liability consequences written down per the comparison table.
• Capability gating: charge and payout capabilities enabled only on the verification state that justifies them.
• Risk-tiered payout schedules and an explicit hold/release rule, not a fixed timer.
• A negative-balance recovery waterfall wired end to end, including an authorized debit instrument and a sized reserve.
• Reserves sized to delivery-and-dispute windows, with a written release rule.
• A split-refund policy covering fee handling, platform-funded cases, and transfer-reversal mechanics.
• An evidence-handoff SLA for disputes that beats the network deadline.
• Tax identifiers collected at onboarding; the reporting obligation mapped to the settlement entity.
• Reconciliation match keys that include the connected-account, transfer, reserve, and payout-batch dimensions.

What this runbook does not cover

This is operations for a live platform. It does not cover choosing the account model in the first place — PSP versus PayFac versus marketplace versus MoR — which is the operations reference linked at the top. It does not cover the mechanics of a single outbound payout that fails on the rail, which is the payout and disbursement failure runbook linked above. It does not cover the decision to hand merchant-of-record status to a third party instead of running your own payments — that is merchant of record vs PSP, and when to switch. And it does not cover building the underlying financial infrastructure — accounts, ledgers, card issuing — which is embedded finance for payment operators. Each of those is a neighbor in the cluster; this runbook is the one that runs the money after the marketplace is live.