Multi-Vendor Order Splitting: Architecture Blueprint

Why order splitting defines marketplace software

A single-store checkout is simple: one merchant, one inventory ledger, one payout. A multi-vendor marketplace breaks that assumption. One cart can contain line items from three sellers — fashion, footwear, and accessories — each with different fulfillment SLAs and commission rules.

If your platform cannot split that cart correctly at order time, everything downstream fails: vendor notifications, shipping labels, commission math, and payouts.

Reference flow

The operating loop looks like this:

Domain model (simplified)

At minimum you need entities that preserve vendor ownership on every line item:

{
  "order_id": "ord_01J8K2",
  "buyer_id": "cus_9f2a",
  "currency": "INR",
  "lines": [
    {
      "line_id": "li_1",
      "vendor_id": "vnd_fashion",
      "sku": "TEE-NAVY-M",
      "amount": 120000,
      "commission_bps": 1000
    },
    {
      "line_id": "li_2",
      "vendor_id": "vnd_shoes",
      "sku": "SNK-WHT-42",
      "amount": 450000,
      "commission_bps": 800
    }
  ]
}

Amounts above are in paise. commission_bps is basis points (1000 = 10%).

Split strategy

1. Split at capture, not at shipping

When payment succeeds, create child fulfillments (or vendor sub-orders) immediately. Do not wait until a warehouse scans a package — vendors need actionable work queues now.

2. Keep a parent order as the buyer contract

Buyers see one order. Internally you hold a parent with children. Refunds and disputes should still resolve against the parent while debiting the correct vendor child.

3. Commission is a first-class ledger entry

Never “eyeball” commission in a spreadsheet after month-end. Write immutable commission rows when the order captures:

type CommissionEntry = {
  orderId: string;
  lineId: string;
  vendorId: string;
  gross: number;
  rateBps: number;
  platformFee: number;
  vendorNet: number;
};

Failure modes to design against

Partial capture / partial cancel

If one vendor cancels a line, recompute platform fee and vendor nets for remaining lines. Buyer totals must stay coherent.

Multi-currency and tax

B2B textile marketplaces often need GST-aware invoices per vendor. Your split model should carry tax identity with the seller, not only the marketplace operator.

Idempotent webhooks

Payment providers retry. Order split jobs must be idempotent on payment_intent_id so you never double-create vendor children.

What TheBazaarNext implements

TheBazaarNext ships this loop as licensed marketplace software: buyer storefront, vendor portal, and admin control plane — typically on a Medusa-oriented commerce engine with Next.js surfaces, deployed on infrastructure you control.

See the full stack on the architecture page, or book a demo to walk an order from cart to payout.