NEWNow shipping: ACP Β· Google UCP Β· Retail MCP integrations
MnT Future
Commerce Platform Engineering

Marketplace Split Payments: Who Files the 1099-Ks in 2026?

CEO UdhayaseelanΒ·Β·5 min read
Marketplace Split Payments: Who Files the 1099-Ks in 2026?

Most marketplace teams pick their payment architecture the same way they pick a hosting region: fast, in week one, and then never think about it again. Stripe Connect ships three ways to route money to a seller β€” destination charges, separate charges and transfers, direct charges β€” and the choice usually comes down to "which one has the shortest integration guide."

That choice is bigger than it looks. It decides who is legally the Third Party Settlement Organization (TPSO) on every transaction that runs through your platform, who holds dispute and chargeback exposure, and β€” as of 2026 β€” who is on the hook for issuing Form 1099-K to every seller who crosses the federal reporting threshold.

That threshold just moved, and most marketplace operators haven't noticed.

The 1099-K threshold just reset, retroactively

For a few tax years, third-party platforms β€” marketplaces, payment apps, rideshare platforms β€” were tracking toward a $600 reporting threshold, a legacy of the American Rescue Plan Act. In 2026, that changed. The One Big Beautiful Bill Act (OBBBA) reinstated the original threshold: over $20,000 and more than 200 transactions per seller per year for TPSO-routed payments, applied retroactively to 2022. The IRS published updated FAQ guidance confirming the reinstated thresholds on October 23, 2025.

Two details in that guidance matter more to a marketplace's engineering team than to its finance team:

First, the $20,000/200-transaction threshold applies specifically to payments settled through a third-party network β€” the TPSO path. Payment-card transactions carry no minimum at all; a single one-cent card charge technically triggers 1099-K reporting obligations. If your marketplace blends card-present and TPSO-routed payment flows, "am I over the threshold" isn't one number, it's two rule sets running side by side.

Second, several states never adopted the higher federal threshold. Massachusetts and Maryland still require reporting at $600. A marketplace operating nationally can't build one reporting rule and be done with it.

None of this is a finance-department problem you can bolt on later. It's a data-model problem, and the data model was decided the day someone chose a Stripe Connect charge type.

Why the charge type is the real decision

Here's the mechanic that gets skipped in most marketplace build docs:

Destination charges put the platform in the position of the charge owner β€” the customer's payment runs through the platform's Stripe account, and Stripe automatically routes the seller's share to their connected account. It's the fastest pattern to implement and the one most tutorials default to.

Separate charges and transfers split the two actions apart: the platform charges the customer under its own account, then issues a separate transfer to the seller on whatever schedule the platform defines. This buys the platform more control over payout timing and reconciliation, at the cost of building (and maintaining) the transfer logic yourself.

Direct charges put the connected seller account in the position of merchant of record β€” the platform takes an application fee on top of a charge that legally belongs to the seller.

Each pattern routes funds differently, and fund-routing is exactly what determines TPSO status, reporting responsibility, and who a disputed charge lands on first. A marketplace that defaults to destination charges because the docs were shorter may have also defaulted into being the party responsible for every seller's 1099-K β€” without anyone on the team deciding that on purpose.

That's not a hypothetical risk. It's the normal outcome of treating a payment-architecture decision as a technical implementation detail instead of what it actually is: a legal and financial classification decision, made in code, usually in the first sprint.

What to check before you ship (or before you retrofit)

If your marketplace is pre-launch, this is the cheapest moment you'll ever have to get it right β€” reverse-engineering a payout architecture after 10,000 transactions have already run through the wrong pattern is a materially harder rebuild than choosing correctly up front.

If you're already live, three questions are worth answering this quarter:

  • Which charge type is your platform actually using, and does your team know, in writing, who that makes the TPSO for reporting purposes?
  • Does your reporting logic separate TPSO-routed volume from card-network volume, given that the two follow different threshold rules?
  • Does your payout system apply state-specific thresholds for sellers in Massachusetts, Maryland, and any other state that hasn't adopted the federal reset?

None of these are optional cleanup items. They're the difference between a marketplace that can hand its finance team an accurate 1099-K seller list every January, and one that's reconstructing it by hand from raw Stripe exports.

We've built exactly this kind of split-payment architecture end to end β€” LOBBI, a two-sided marketplace we engineered from scratch, runs real-time payouts through this same class of decision, made deliberately instead of by default. It's the same architecture-first approach behind every marketplace platform we build.

Which Stripe Connect charge type should a marketplace use for split payments, and who has to file 1099-Ks?

The charge type (destination charges, separate charges and transfers, or direct charges) determines who is the Third Party Settlement Organization for tax purposes. Under the OBBBA-reinstated 2026 threshold, TPSOs must issue Form 1099-K to sellers over $20,000 and 200+ transactions annually, while card-network transactions carry no minimum β€” so the routing pattern you pick decides your reporting obligation, not the other way around.

Getting the payment architecture right the first time is a smaller job than untangling it later. If your marketplace's split-payment logic hasn't been reviewed since launch, that's worth a second look before next tax season closes the gap on you.

Not sure which charge pattern your marketplace is actually running, or what it's committed you to? Book a free strategy session with MnT Future β€” we'll map your current payment architecture against the 2026 reporting rules and tell you plainly whether it needs a fix.

Next step

Tell us what you're building. We'll show you how we'd build it.

A free strategy session with a senior consultant: data model, APIs, and a scalability plan. Or a free agent-readiness audit of your store.