Marketplace Payments: Paying Sellers Without Becoming a Money Transmitter

Building a marketplace looks like a product problem until the first payment arrives, at which point it becomes a regulatory one. The moment your platform receives a buyer's money and later pays a seller, you are holding funds that belong to someone else — which is the activity money transmission licensing exists to regulate, in most states, with licensing requirements that are expensive and slow. There are established structures that avoid this, and the choice between them determines your liability for chargebacks, your obligations when onboarding sellers, your payout timing, and your tax reporting duties. It is also difficult to change later. This guide covers the architecture decision and everything that follows from it.

The custody question

Everything in marketplace payments follows from one question: does money belonging to another party ever sit in an account you control?

If yes, you are potentially engaged in money transmission — receiving funds from one party for transfer to another — which most states license, with requirements typically including application processes in each state, surety bonds, minimum net worth, permissible investment rules, examinations, and ongoing reporting. The state-by-state structure is the same fragmentation our licensing analysis documents, and building it out is a multi-year, multi-million-dollar undertaking that very few marketplaces intend when they start.

The structures that avoid it:

• Merchant of record. You aren't transmitting money between two parties — you're selling to the buyer and separately buying from the seller. The funds are yours in between.
• Payment facilitator arrangements, where a licensed provider holds funds and settles directly to sellers as sub-merchants. Your platform orchestrates but never takes custody.
• Agent-of-payee arrangements, available in some states, where a platform acting as the seller's agent for receiving payment may be exempt — with the seller's obligation to the buyer discharged on receipt. Availability and requirements vary considerably.
• Direct settlement, where funds route from the buyer to the seller's own merchant account and the platform bills its fee separately.

The practical instruction: this is a question for counsel before you launch, not after you scale. The cost of discovering the problem at volume — retroactive licensing exposure, an emergency architecture migration, and the seller communication that comes with it — is dramatically higher than the cost of the initial conversation.

Three models compared

	Merchant of record	Payment facilitator	Direct settlement
Who the buyer contracts with	Your platform	The seller	The seller
Statement descriptor	Your name	Typically seller name, sometimes with platform	Seller name
Chargeback liability	Yours	Sub-merchant, with platform exposure in practice	Seller's
Seller onboarding burden	Supplier onboarding only	Full underwriting and verification per seller	Seller arranges their own
Buyer experience	Seamless — one checkout, one brand	Seamless	Fragmented
Money transmission exposure	Generally avoided	Generally avoided via the provider	Avoided
Tax reporting	You report supplier payments	Reporting obligations attach	Provider or seller
Control over the experience	Highest	High	Lowest

Two observations. Merchant of record is the simplest and the most exposed — you get complete control of the buyer experience and complete ownership of every dispute, refund, and quality complaint, plus responsibility for sales tax on the transaction in many contexts. It works well where you effectively control the offering and poorly where sellers are genuinely independent.

Direct settlement is the least exposed and the worst product. Buyers seeing unfamiliar merchant names, separate checkouts, and inconsistent experiences convert worse and dispute more — the descriptor recognition problem our chargeback guide identifies as a self-inflicted dispute source.

Most marketplaces at scale land on the facilitator model because it balances these — seamless experience, distributed liability, no custody — at the cost of real onboarding and monitoring obligations.

Seller onboarding and verification

Under a facilitator model, each seller becomes a sub-merchant, and onboarding them carries obligations that platforms consistently underestimate.

What's typically required:

• Identity verification of the individual or beneficial owners.
• Business verification — entity existence, tax identification, and address.
• Screening against sanctions and restricted party lists.
• Bank account verification, confirming the payout account belongs to the seller — which is a fraud control as much as a compliance one, per the account verification our ACH guide describes.
• Underwriting — what they sell, expected volume, and whether the category is permitted.
• Prohibited activity screening, since card network rules and your provider's policies restrict certain categories entirely.

The tension every marketplace faces: onboarding friction reduces fraud and reduces seller acquisition. A platform whose growth depends on seller supply is under permanent pressure to simplify onboarding, and the sellers most deterred by verification are disproportionately the ones you'd want to deter.

The approach that resolves it: tiered onboarding. Light verification to list and transact at low volume, with progressive verification triggered by volume, payout amount, or risk signals. That gets sellers moving while ensuring anyone handling meaningful money has been properly checked — and it mirrors the staged-cost logic our decisioning guide applies to underwriting.

Chargeback liability allocation

Decide this before launch and encode it in both the seller agreement and your payout logic, because the default outcome is that you absorb everything.

The contractual allocation should state clearly that the seller is responsible for disputes arising from their transactions, that the platform may deduct chargebacks and fees from future payouts, that the platform may hold reserves, and what happens if a seller's balance is insufficient.

The practical problem is that contracts don't produce money. A seller who has been paid out, has no future volume, and has no assets is judgment-proof in practice — and the platform absorbs the loss regardless of what the agreement says. This is why the contractual and operational answers have to work together:

• Payout timing as the primary control — funds not yet released can be clawed back against a dispute.
• Rolling reserves on higher-risk sellers, holding a percentage of volume for a period, per the mechanics in our reserves guide.
• Negative balance handling — what happens when disputes exceed available funds, and whether you can debit the seller's account.
• Representment support. Sellers have the evidence to fight a dispute; platforms have the process. A system that collects delivery confirmation and communication records at transaction time makes representment possible — and without it, disputes are lost by default.

And the strategic point: your aggregate dispute ratio is a platform-level risk. Individual seller disputes roll up into a number your provider watches, and a handful of bad sellers can threaten processing for everyone on the platform. That makes seller quality a payments problem rather than only a marketplace-quality problem.

Payout timing and fraud exposure

Payout speed is a competitive feature and a risk control, and they point in opposite directions.

Sellers want money immediately. Fast payouts win supply, particularly against competitors, and for small sellers the working capital difference is genuine.

Fast payouts eliminate recovery. A fraudulent transaction discovered after payout is money gone — the seller has it, the buyer disputes, and the platform funds the difference. The exposures worth naming:

• Collusive fraud, where a fraudster is both buyer and seller, transacts with stolen cards, takes the payout, and disappears before the disputes arrive.
• Non-delivery, where a seller takes payment and doesn't ship.
• Account takeover of a legitimate seller, with payout details changed.
• Triangulation, where goods are fulfilled with stolen cards elsewhere.

The design that balances these: risk-based payout timing rather than a single schedule. New sellers on a delay; established sellers with clean history accelerated; instant payout available as a paid option where the risk is priced; and holds triggered by specific signals — unusual volume, a change in payout details, a spike in disputes, or shipping addresses inconsistent with the seller's pattern.

Payout detail changes deserve their own control. A change to a seller's bank account is the highest-risk event in the lifecycle, since it's the signature of account takeover. Verification through a channel other than the one used to make the change — and a hold on payouts for a period afterward — prevents the most common version of this attack.

Splits, fees, and refunds

The mechanics that generate most support volume:

• Split payments divide a transaction between seller proceeds and platform fee at the time of charge, which is cleaner than paying the seller in full and invoicing your fee separately.
• Multi-seller carts require splitting one buyer payment across several sellers, and the refund and dispute logic on a partially refunded multi-seller order is where implementations break.
• Refunds need to reverse the split correctly — including whether your platform fee is refunded. Decide this deliberately and state it in the seller agreement, because sellers assume the fee comes back and platforms frequently don't return it.
• Partial refunds compound the above and should be tested explicitly rather than assumed to work.
• Processing costs — decide whether they're absorbed by the platform or passed to sellers, and state it clearly, since a seller discovering an unexpected deduction is a support ticket and a trust problem.
• Descriptors should be recognizable to the buyer, which for marketplaces usually means combining platform and seller identity. This is one of the cheapest dispute reductions available.

Tax reporting

Platforms that settle payments to sellers generally carry information reporting obligations, and the operational implications are larger than the legal ones.

What matters practically:

• Collect taxpayer information at onboarding, not at year end. Chasing tax identification from thousands of sellers in January is a well-known operational disaster, and sellers who have already been paid have little incentive to respond.
• Thresholds have changed repeatedly in recent years and several states impose lower ones than federal law, so a platform operating nationally needs to track both.
• Backup withholding may apply where taxpayer information is missing or fails validation, which means you may be required to withhold from payouts — an unpleasant surprise for a seller and a support burden for you.
• Validate at collection. A taxpayer identification number that fails matching is discovered at filing time otherwise, which is the worst moment.
• Sales tax is a separate question, and marketplace facilitator laws in many states place collection obligations on the platform rather than the seller — which interacts with the nexus rules our tax guide describes.

Monitoring the seller base

Onboarding is a point-in-time check; sellers change. Ongoing monitoring is what prevents an approved seller from becoming a platform-level problem.

What to watch:

• Dispute rate by seller, against a threshold that triggers review — and remember these aggregate to your platform ratio.
• Sudden volume changes, particularly a dormant seller becoming very active.
• Refund rate, which distinguishes a quality problem from a fraud problem.
• Payout detail changes, as above.
• Category drift — a seller listing items outside what they were approved for, which is how prohibited categories enter a platform.
• Buyer complaint patterns, which frequently precede disputes and are the earliest signal available.
• Linkage signals — shared devices, addresses, or bank details across supposedly independent sellers, which is how collusive rings are found.

The escalation ladder should be graduated: increased monitoring, payout holds, reserve imposition, listing restrictions, and finally offboarding — with each step documented, since a seller removed without record is a seller who disputes the decision.

Choosing an architecture

The decision criteria, honestly stated:

• How independent are your sellers? If you effectively control the offering, quality, and fulfillment, merchant of record reflects reality. If sellers are genuinely independent businesses, a facilitator model does.
• Who should own quality disputes? Merchant of record means every complaint about every seller is yours.
• What's your risk appetite and capacity? The facilitator model requires an underwriting and monitoring function that is a real ongoing cost.
• How much experience control do you need? Direct settlement fragments the buyer experience meaningfully.
• What's your scale trajectory? Some structures that work at small volume attract regulatory attention at large volume.
• Can you change later? Migrating models means re-onboarding every seller and potentially re-collecting payment credentials from buyers — the portability problem our tokenization guide describes, at platform scale.

The recurring advice: get counsel involved before launch, choose the model that matches what your platform actually is, and build the seller agreement and payout logic around it from the start. Retrofitting is expensive in every direction.

Frequently asked questions

---

This guide is educational and does not constitute legal advice. Money transmission licensing, agent-of-payee exemptions, marketplace facilitator tax obligations, and information reporting thresholds vary by state and change; consult qualified counsel before selecting or changing a payment architecture.