Multi-Vendor Is Not One Feature: 18 Workflows Every Marketplace Must Model

A vendor’s “multi-vendor” checkbox usually means one thing: split checkout. Running a marketplace for real means owning at least 18 separate workflows across seller identity, payment settlement, disputes, tax and safety compliance, each with its own data owner, deadline and audit trail. This is written against PCI DSS v4.0.1, EU DSA Article 30, the EU General Product Safety Regulation (applicable since 2024-12-13), DAC7, the US Form 1099-K threshold restored for the 2026 tax year, and the EU VAT deemed-supplier rule under Article 14a. Treat the regulatory specifics as a starting point, not a citation: the DAC7 deadlines, the EU VAT Article 14a text and the DSA Article 30 suspension wording below are summarised from official overview pages and remain unverified against the primary legislation, so confirm each against the legal text — and with counsel — before you build an obligation around it.

The 18 workflows every multi-vendor marketplace must model, grouped into five

Score your own platform against this list before you compare vendor feature pages. Multi-vendor commerce breaks into five groups, and each group breaks into three or four workflows — 18 in total, not one checkout feature.

• Identity and onboarding (4 workflows): KYC identity verification, DSA Article 30 trader-traceability collection, DAC7 due-diligence data capture, and PCI DSS Requirement 12 documentation of each seller sub-account relationship.
• Money movement (4 workflows): charge-model selection — destination charges versus separate charges and transfers — payout timing and reserve policy, per-seller settlement statements, and payout clawback on late refunds or chargebacks.
• Disputes and returns (4 workflows): chargeback attribution to the responsible seller, evidence collection per seller, cross-vendor return and refund reconciliation, and platform-versus-seller liability for return shipping and restocking.
• Tax and reporting (3 workflows): US Form 1099-K threshold tracking, US state marketplace-facilitator sales tax collection, and EU VAT deemed-supplier plus DAC7 reporting.
• Moderation and product safety (3 workflows): policy-violation content moderation, GPSR Safety Gate regulator takedown-order routing, and trader-versus-private-seller classification, which gates which duties apply to a given seller.

That is 4+4+4+3+3, eighteen workflows. A marketplace that has built split checkout and a vendor dashboard has typically modelled two or three of the eighteen, not all of them.

Each workflow needs three things recorded against it: a data owner, a deadline, and an audit trail. The rest of this article applies that same three-column test to each group in turn.

You should now see: a five-group, 18-item checklist you can score your own platform against before reading further.

Decide who is the merchant of record before you build anything else

The merchant of record is the entity a card network and a tax authority hold liable for a transaction. A marketplace has to decide upfront whether that is the platform or the individual seller, because card networks do not support splitting one disputed charge across multiple sellers.

Stripe Connect’s two main charge models put that liability in different places by default. With destination charges (opens in a new tab), the platform’s own Stripe account is responsible for a connected account’s processor fees, refunds and disputes, even though the funds settle to the seller. With separate charges and transfers, the charge itself belongs to the platform’s account from the start, so disputes and fees are still debited from the platform’s balance (opens in a new tab), not the seller’s — “separate” describes the API call, not who bears the risk.

{
  "amount": 5000,
  "currency": "usd",
  "payment_method": "pm_card_visa",
  "confirm": true,
  "on_behalf_of": "acct_1SellerConnectedAccount",
  "transfer_data": {
    "destination": "acct_1SellerConnectedAccount"
  },
  "application_fee_amount": 500
}

{
  "amount": 5000,
  "currency": "usd",
  "payment_method": "pm_card_visa",
  "confirm": true
}

The transfer to the seller is a second, independent API call made once the order is fulfilled:

{
  "amount": 4500,
  "currency": "usd",
  "destination": "acct_1SellerConnectedAccount",
  "transfer_group": "order_8261"
}

flowchart LR
    subgraph Destination["Destination charge"]
        D1["Buyer's card charged"] --> D2["Platform account<br/>(merchant of record)"]
        D2 -->|"transfer_data.destination"| D3["Seller connected account"]
        D2 --> D4["Dispute + fees debited here"]
    end
    subgraph Separate["Separate charge and transfer"]
        S1["Buyer's card charged"] --> S2["Platform account<br/>(merchant of record)"]
        S2 -->|"separate Transfer API call"| S3["Seller connected account"]
        S2 --> S4["Dispute + fees debited here"]
    end

Visa’s published chargeback process (opens in a new tab) — inquiry, first chargeback, pre-arbitration, arbitration, appeal — assumes one merchant of record per disputed charge, and has no native step for splitting a shared-cart dispute across vendors.

This decision has to be made before checkout is built. Per-seller charges give clean dispute attribution at the cost of more payment-service-provider setup per seller; one aggregated cart charge is simpler to build but needs a custom line-item-to-seller mapping to attribute a dispute later. Every other workflow in this framework — settlement statements, dispute attribution, tax remittance, payout reserve policy — inherits whichever entity was named merchant of record here.

You should now see: which entity is the merchant of record on your own platform, and which charge model encodes that choice.

Model seller onboarding as a state machine, not a one-time signup form

Split-payment processors gate payouts, not listings, behind identity verification. A seller can finish registration and publish products on Stripe Connect (opens in a new tab) or Adyen for Platforms (opens in a new tab) while still unable to receive money until identity, business and bank details clear review.

Track a distinct payouts-enabled flag sourced from the processor’s own account object, and block listing actions — not just payouts — until that flag is true. Otherwise a seller makes a sale, waits weeks for a payout stuck pending, and files a support ticket a signup-time check would have prevented.

Pull a test seller’s own account object to see the pending state directly — the shape below documents the fields Stripe’s onboarding docs describe, not a captured response:

{
  "id": "acct_<CONNECTED_ACCOUNT_ID>",
  "charges_enabled": true,
  "payouts_enabled": false,
  "requirements": {
    "currently_due": [
      "individual.verification.document",
      "external_account",
      "tos_acceptance.date"
    ],
    "past_due": [],
    "disabled_reason": "requirements.past_due"
  }
}

Expected output:

stateDiagram-v2
    [*] --> AccountCreated
    AccountCreated --> ListingsBlocked
    AccountCreated --> DetailsSubmitted : seller submits KYC data
    DetailsSubmitted --> UnderReview : processor verifies identity
    UnderReview --> DetailsSubmitted : additional document requested
    UnderReview --> PayoutsEnabled : requirements.currently_due empty
    ListingsBlocked --> ListingsAllowed : payouts_enabled becomes true
    PayoutsEnabled --> ListingsAllowed
    ListingsAllowed --> [*]

DSA Article 30 (opens in a new tab) requires platforms that let EU consumers contract with third-party traders to collect the trader’s identification, contact details, trade-register number where applicable, and a self-certification of legal compliance before the trader can offer products — and to suspend the trader if that information is missing or unverifiable. Classify each seller as trader or non-trader at onboarding, because Article 30’s identity and trade-register requirements apply only to traders; a single hard-coded flow wrongly rejects private sellers who have no trade-register number.

DAC7 (opens in a new tab) due-diligence data has to be captured at onboarding even for sellers who may later qualify for the fewer-than-30-transactions, under-€2,000 exemption, because the exemption is evaluated after the fact, not predicted at signup. PCI DSS v4.0.1 (opens in a new tab) Requirement 12 treats each seller sub-account or hosted-onboarding integration that touches cardholder data as a third-party service provider relationship that must be documented, not an internal implementation detail.

You should now see: on your own platform, which accounts are merely created versus payout-enabled and trader-verified.

Attribute a single disputed charge back to the responsible seller

A buyer who disputes a card charge covering items from three different sellers produces one dispute against one aggregated charge, if checkout was built on a single per-cart charge. Nothing in that shape tells you which seller’s item is contested.

sequenceDiagram
    participant Buyer
    participant Platform
    participant Support
    participant SellerA
    participant SellerB
    participant SellerC
    Buyer->>Platform: Checkout cart (item A, item B, item C)
    Platform->>Platform: One aggregated charge, one charge_id
    Buyer->>Platform: Files dispute against charge_id
    Platform->>Support: No line-item-to-seller mapping stored
    Support-->>SellerA: Which seller is responsible?
    Support-->>SellerB: Which seller is responsible?
    Support-->>SellerC: Which seller is responsible?

Store a line-item-to-seller mapping against the charge ID at checkout time, whichever merchant-of-record model you chose earlier, so a dispute can be attributed automatically (opens in a new tab) instead of manually by support. Hold a rolling reserve, or delay payouts by a fixed number of days matched to a realistic dispute window, on new or high-risk seller accounts, and document the platform’s clawback right in the seller agreement.

Releasing payouts immediately with no reserve leaves the platform’s processor balance negative when a chargeback lands after the seller has already withdrawn the funds. Neither Visa’s (opens in a new tab) nor Mastercard’s (opens in a new tab) merchant-facing dispute process performs this attribution; both assume a single merchant of record, so the attribution logic above is the platform’s own build, not something the card network provides.

You should now see: a disputed charge on a test multi-seller order, traced back to a specific seller record without a manual support lookup.

Reconcile cross-vendor returns before you reconcile settlement

A cross-vendor return carries two separate obligations a single-seller store never has to distinguish: refunding the buyer, and clawing back or netting the seller’s payout for that line item. Skip the second half and your settlement statements drift from what actually happened.

A US seller who crosses the $20,000-and-200-transaction Form 1099-K (opens in a new tab) threshold mid-year, then disputes the January total, is usually right if the figure was built from gross settled payments without reconciling refunds and returns against the running total first. Reconcile refunds and returns against each seller’s running gross-payment total continuously, and expose a year-to-date figure in the seller’s dashboard so the reported number is not a January surprise.

The $20,000/200-transaction threshold is the federal figure restored for the 2026 tax year by the One Big Beautiful Bill Act of 2025; individual state thresholds were not checked here, and some states have historically diverged from the federal figure. Returns policy also has to decide, per the merchant-of-record choice made earlier, whether the platform or the seller absorbs return shipping and restocking cost — a gap that is usually invisible until the first disputed return.

You should now see: where, in your own system, a refund updates the same running total that feeds tax reporting.

Collect and remit tax separately across four jurisdiction-gated duties

US marketplaces qualify as third-party settlement organizations under IRS rules and must issue a seller a Form 1099-K (opens in a new tab) once that seller’s payments exceed $20,000 and 200 transactions in a calendar year — the figure current for the 2026 filing year. Every US state that levies sales tax now has a marketplace facilitator law (opens in a new tab) requiring the marketplace, not the individual seller, to collect and remit sales tax on facilitated transactions, but these laws generally do not extend to a seller’s direct, off-platform sales.

Since 1 July 2021, EU VAT Article 14a (opens in a new tab) treats the marketplace as the deemed supplier, liable to charge and remit VAT itself, for any B2C goods sale it facilitates where the seller is not established in the EU, and for imported consignments valued at €150 or less regardless of seller location. Under DAC7 (opens in a new tab), EU platform operators must complete seller due-diligence data collection and report qualifying sellers’ data to the tax authority annually; sellers of goods making fewer than 30 transactions and less than €2,000 in a calendar year are exempt from reporting.

flowchart TD
    Start{"Where is the seller established,<br/>and who is the buyer?"} -->|"US seller, US buyer"| US1{"Payments over $20,000 and<br/>over 200 transactions this year?"}
    US1 -->|Yes| US2["Issue Form 1099-K"]
    US1 -->|No| US3["No 1099-K this year"]
    Start -->|"Buyer in a US state with sales tax"| US4["Marketplace collects and remits<br/>state sales tax as facilitator"]
    Start -->|"Non-EU seller, EU B2C buyer"| EU1["Platform is deemed supplier:<br/>charge and remit EU VAT"]
    Start -->|"Any seller, EU-based platform"| EU2{"Fewer than 30 transactions<br/>and under EUR 2,000?"}
    EU2 -->|Yes| EU3["Exempt from DAC7 reporting"]
    EU2 -->|No| EU4["Report seller data under DAC7"]

These four duties are independent and jurisdiction-gated. A US-only marketplace has no DAC7 or EU VAT deemed-supplier obligation, and an EU-only marketplace has no 1099-K obligation, so one compliance module built for all four invites collecting data the operator has no legal basis to hold.

You should now see: each of your marketplace’s actual seller and buyer jurisdictions mapped to only the tax duties that apply there.

Route regulator safety orders separately from policy moderation

A national market-surveillance authority’s takedown order is a legally distinct event from a user-reported policy violation. It needs its own queue, routing and response-time clock, not the standard content-moderation queue.

Under the EU General Product Safety Regulation (opens in a new tab), applicable since 13 December 2024, marketplace operators must register a single point of contact on the EU Safety Gate system and act on market-surveillance-authority orders to remove or disable listings for unsafe products. DSA Article 30’s (opens in a new tab) trader-suspension duty and GPSR’s Safety Gate duty are separate regulations that vendor documentation often conflates: Article 30 governs trader identity and traceability, GPSR governs product-safety takedown response.

Reuse the trader/non-trader classification captured at onboarding so Article 30’s suspension trigger applies only to sellers in scope, not to every account. Whether GPSR’s consumer-notification duty for a later-discovered unsafe product applies to every marketplace, or only to Very Large Online Platforms under the DSA’s separate user-count threshold, depends on a user-count threshold this article does not settle for you — check your own numbers against it before building the duty in as a blanket requirement.

You should now see: a distinct queue, contact point and SLA clock for regulator safety orders, separate from your policy-violation moderation queue.

What this framework does not cover and how to verify it for your jurisdiction

Three specifics here are deliberately not restated from memory or from a summary page, because getting them wrong is expensive and this is not legal advice: DAC7’s exact due-diligence and reporting deadlines, the full operative text of EU VAT Article 14a, and Article 30’s precise suspension-trigger wording. Read them in EUR-Lex, or have counsel read them, before you build a control around any of the three. An attempt to pull them from EUR-Lex directly on 5 August 2026 returned nothing usable. State-level US sales-tax and 1099-K thresholds were not checked state by state against the federal $20,000/200-transaction figure, and some states may diverge from it.

This framework does not cover platform-specific implementation. Tools such as Sharetribe (opens in a new tab) and CS-Cart Multi-Vendor (opens in a new tab), or Bagisto, each encode these 18 workflows differently, so this article gives workflow boundaries, not a product recommendation.

Two checks you can run directly: pull your own payment processor’s account object for a test seller and confirm which fields gate payouts versus listings, and read DSA Article 30 and the GPSR directly on EUR-Lex against your own trader classification and seller jurisdictions, rather than relying on secondary summaries. The eighteen-workflow, five-group structure is the durable part to reuse — the specific thresholds, deadlines and article numbers above should be re-verified on a fixed schedule, since the 1099-K threshold, the DAC7 exemption limits and the PCI DSS version have all changed within the last two years.

You should now see: a dated list of what to re-verify before treating any of the eighteen workflows as compliant, plus two checks you can run yourself.

Limitations

This framework does not cover platform-specific implementation detail, custom-built marketplaces, or verticals with their own regulatory layer such as food delivery or short-term rentals. It does not resolve UK, Canadian, Australian or other non-EU, non-US tax and safety regimes — the four duties in this article are scoped to the US and EU only. No account of this framework was tested against a running marketplace; every claim traces to vendor documentation or primary legal text, not to an operated platform. Treat this as a checklist for workflow boundaries, not as legal or tax advice for a specific business.