Adding a Multi-Vendor Marketplace to an Existing Platform

Challenge

The platform already owned customer accounts, carts, card payments and gift cards. It needed multi-seller catalogs and inventory — but replacing its core with an off-the-shelf commerce product would have meant migrating everything that already worked. And stock had to stay correct even when one side of the integration was briefly unreachable.

Approach

• Keep one system of record. The existing application remains the "marketplace brain" for sellers, carts, orders and payments. A headless commerce engine is used purely as an internal catalog and stock service, reachable only server-to-server.
• Isolate sellers structurally. Each seller gets its own channel and stock location.
• Make checkout predictable. Price and availability are snapshotted into the cart, so totals don't shift mid-checkout.
• Decouple stock from payment. Stock is deducted after payment through queued jobs, so the commerce engine never needs to know about payments.

Implementation

• A GraphQL client for the commerce engine's catalog and stock operations.
• A seller lifecycle: application → admin approval (provisioning a channel and stock location) → suspension with recorded reason → reactivation, plus listing and profile review.
• A stock-sync worker that groups adjustments per seller, retries with exponential back-off and surfaces failures in an admin queue with manual retry.
• Mixed carts that split marketplace and gift card items over the existing card payment.
• Seller payouts, statements, charges, pickup locations and return workflows across buyer, seller and admin views.

Outcome

Sellers are onboarded, moderated and paid inside the platform customers already use. Inventory reconciles across transient failures instead of silently drifting.

Technical perspective

Splitting ownership is the hard part: orders and payments live in one system, stock in another. That makes the integration eventually consistent by nature, so retries, idempotency and failures an operator can see and act on are design requirements, not afterthoughts.