B2B marketplace split checkout: how to split cart, payments, payouts and invoices

A B2B marketplace looks simple from the buyer perspective: choose products from three suppliers, click order, get one coherent checkout. Operationally it is several independent transactions: different warehouses, delivery dates, VAT rates, freight costs, discount thresholds, credit limits, invoices and return policies.

If the platform treats the cart like a normal single-vendor order, all revenue lands in one place and finance manually splits commissions, notes, payouts and adjustments. If you force the buyer into three separate checkouts, accounting improves, but buying experience worsens and abandonment rises.

A good split checkout is not only a payment integration. It is a domain model for orders, settlements, fulfilment and risk control. First decide who is merchant of record, who issues invoices, who handles chargebacks, who owns delivery and when the vendor receives funds.

In marketplace discussions people use "split checkout", "split payment" and "split order" interchangeably. That is dangerous because each area has different technical, legal and accounting consequences.

• Split cart/UX: the buyer sees one cart, but lines are grouped by vendor, warehouse, delivery method or commercial terms.
• Split order: after confirmation, vendor orders are created, for example `ORD-1001-A`, `ORD-1001-B`, `ORD-1001-C`, with separate fulfilment statuses.
• Split payment: one authorization or payment funds multiple transfers, platform commission and shared costs.
• Split invoice/reconciliation: invoices, credit notes, taxes, refunds, chargebacks and payouts must reconcile in ERP or accounting.

Stripe Connect describes two important patterns. Destination charges work when a payment has one primary seller and the platform collects an application fee. Separate charges and transfers let the platform take payment and later transfer funds to multiple connected accounts. Stripe explicitly notes that this model typically needs a ledger to know where funds should go.

For B2B marketplaces, a "charge now, split later" model with a ledger often wins because an order can involve partial availability, different shipping dates, credit approval, manual vendor confirmation or split shipment. It gives control, but increases responsibility for reconciliation and compliance with the agreed legal model.

Do not choose the payment provider before the operating model. First answer: is the platform merchant of record, or is the vendor? Can funds pass through the platform? When does the vendor earn payout rights? What happens on a partial refund? Who pays processor fees and chargebacks?

The Medusa marketplace recipe describes a pattern where you create a marketplace module with vendor models, link vendors to products and orders, and customize the order creation process so one order can split into multiple vendor orders. That is a strong starting point because you are not fighting a closed SaaS checkout.

At GMI we usually design vendor ownership at cart-line level: vendor ID, warehouse, tax class, shipping method, commission rule, return policy, minimum order value and fulfilment SLA. After the complete-cart workflow, the system creates a parent order for the buyer and child/vendor orders for operations.

NestJS works well as the domain layer when rules go beyond the commerce core: B2B approval flow, trade credit, buyer limits, freight quotes, custom pricing, vendor scoring, ERP/PIM/WMS integration and document export to accounting.

In a B2B marketplace, "who issues the invoice?" is as important as "how do we split the payment?". One buyer can receive one invoice from the platform, multiple invoices from vendors, or an aggregate document plus partial documents. Each variant changes tax logic, credit-note responsibility and ERP integration.

The ledger should store not only transfers, but also why the transfer exists: order line, vendor, commission, shipping cost, tax, refund, adjustment, chargeback, manual correction. Without that, finance exports CSV files and manually hunts differences between payment provider, ERP and marketplace admin.

During DDT, invite finance and the client counsel, not only the product owner. Split checkout touches vendor contracts, platform terms, KYC/KYB, tax reporting, chargebacks and delivery responsibility.

The happy path is easy: buyer pays, vendor ships, platform takes commission. Real complexity starts with partial returns. What if the buyer returns one line from three vendors and shipping cost was shared? What if one vendor cancels fulfilment after payment authorization?

The system must handle partial capture, partial refund, platform fee refund, payout adjustment, invoice correction and order status update. If vendor payout happened before the return window closed, you need reserve rules, deductions or later compensations.

Chargebacks are sharper because the payment provider can debit the platform while the dispute relates to a specific vendor or shipment. Without an order line -> payment -> transfer -> invoice -> shipment relationship, responsibility is hard to establish quickly.

The UX goal is not to pretend the marketplace is one seller. The goal is to make the buyer understand what they buy, from whom, when it arrives and which documents they receive, without making them repeat payment three times.

A strong split cart shows vendor groups, different deliveries, minimum order values, timelines, return terms and invoices in a scannable way. For B2B, also include PO number, cost center, approval flow, trade credit, buyer limit, company account and reorder.

A Next.js storefront or React Native app should consume the same API contracts. If mobile has a simplified cart without vendor and split-shipment information, it will return later as claims, wrong expectations and support cost.

At GMI we start with DDT because split checkout without discovery quickly becomes an uncontrolled financial/legal project. We map platform, vendor and buyer roles, merchant-of-record, funds flow, invoices, refunds, ERP/PIM/WMS integrations, fulfilment and the minimum MVP scope.

A typical stack is MedusaJS as headless commerce core, Next.js storefront, NestJS for marketplace domain services, PostgreSQL for ledger and transaction data, Redis/queues for asynchronous processes and integration with Stripe Connect, Adyen, PayPal or a local payment provider. If mobile is a sales channel, we add React Native/Expo on the same API contracts.

After DDT we can discuss fixed price because risks are known: payment model, tax/VAT, payout timing, vendor onboarding, admin/vendor dashboards, refunds, observability and handover. The client keeps source code and architecture without vendor lock-in.

Use this list before choosing a platform, payment provider or software partner. Without these answers, split checkout may look good in a demo and fail in operations.

• Who is merchant of record: platform, vendor or mixed model?
• Does the buyer receive one invoice, multiple invoices or an aggregate document plus vendor documents?
• Should payment use destination charge, separate charges and transfers, escrow-like hold, trade credit or invoice-first?
• When does the vendor earn payout rights: authorization, capture, shipment, delivery or return-window end?
• How do we handle partial refund, chargeback, cancellation of one line and commission correction?
• How does the ledger reconcile payment provider, vendor orders, invoice documents and ERP?
• Which MVP elements are mandatory: vendor onboarding, KYB/KYC, vendor dashboard, admin disputes, split shipment, credit limits?