Marketplaces look like one integration on the outside: plug in the connector, and your products appear on Amazon or eBay. Inside, the connector is doing five different jobs at five different cadences, and each one can fail without the others noticing. I have spent enough hours in marketplace integration failures to know that the phrase "the connector does it" is where the trouble starts. The connector does not do it. The connector is the messenger, and the message is the architecture.

The five flows inside every marketplace connection

  • Listings. Product data out to the marketplace: titles, descriptions, images, prices, EANs.
  • Stock feeds. Availability out to the marketplace, constantly, from one authoritative record.
  • Orders. Sales in from the marketplace, becoming orders in the ERP.
  • Payouts. Money in from the marketplace, needing reconciliation against fees, refunds and adjustments.
  • Returns. Return requests and refunds, governed by marketplace rules and your policy.

Map those five flows for every marketplace before you buy any middleware, because the system fragmentation article shows what happens when channels are bolted on without a map: the gaps become spreadsheets, and the spreadsheets become the system.

Listings and the master data trap

The listing flow looks simple and hides the worst data trap in retail. Your ERP product master says the item is "Men's Cotton Oxford Shirt, Navy". Amazon wants a title that fits its search behaviour, images at its specs and attributes in its taxonomy. If you push the ERP description verbatim, the listing underperforms. If marketing rewrites titles per marketplace, you now have multiple truths for the same product, and every one of them drifts.

The fix is a marketplace specific description field set in the master data, maintained once and published everywhere. The Drapers news coverage of UK fashion retail is full of examples where master data quality decided how well brands performed on marketplaces, because the listing quality is the first impression and the last one in a search result.

Stock feeds: speed and authority

The stock feed is the flow that sells or oversells you. The marketplace publishes whatever number you send, so the question is what number you send and how often. The answer to both is dictated by your architecture: one stock authority in the ERP, publishing sellable quantities per marketplace, at the fastest cadence the marketplace supports, with reservations already applied.

The overselling problem covers the reservation mechanics in detail. The marketplace version adds one rule: when the feed fails or stalls, stop selling on that marketplace automatically. A marketplace running on a stale stock number is a machine for manufacturing refunds. Before the ERP takes ownership of that feed, marketplace integration should be a named requirement on your retail ERP selection checklist.

Orders and fulfilment back to the marketplace

Marketplace orders arrive in bulk or via webhook, each with a fulfilment deadline that the marketplace enforces with seller metrics. The ERP must convert them into orders, allocate stock, trigger fulfilment and send the tracking number back within the window. The timing pressure is real, and it is why order flow design matters: the order should land in the warehouse queue without a human copying anything.

This is also where the marketplace's seller performance data becomes your data. The IMRG research programme has tracked the growth of marketplace trading in UK online retail for years, and the pattern is consistent: the retailers who treat marketplace service levels as seriously as their own website metrics are the ones who keep the channel profitable as it scales.

Payouts and the reconciliation nobody enjoys

Marketplace payouts arrive as lump sums covering many orders, minus fees, refunds, returns and adjustments. Reconciling that against individual orders is the most disliked task in multichannel retail, and it is where finance teams quietly lose hours every week. The flow needs the marketplace payout report mapped to the ERP, so every fee line lands in the right nominal account and every order can be traced to its share of the payout. This is pure margin work, and the unified inventory guide shows why the same discipline applies to the money side as the stock side.

Returns and the marketplace rules

Marketplace returns run on the marketplace's rules, not yours. Return requests are raised through the platform, refunds are expected within the platform's window, and the item may come back to your warehouse or be disposed of at your instruction. The ERP needs to receive the return, value it, and feed the disposition back to the marketplace. Returns management covers the margin side of this process; the marketplace adds the compliance layer on top.

The architecture that keeps it honest

Keep the architecture simple and the ownership explicit. One stock authority, one order flow, one set of master data, five defined interfaces per marketplace, and a named owner for each interface. When the marketplace changes an API or the connector vendor changes a pricing model, the owner notices before the customers do. The single record model and the platform versus best of breed comparison both feed into this decision, because the marketplace integration quality is often the deciding factor in which architecture a retailer should choose.

The closing observation from client work is that marketplace integrations fail in the quiet hours, not the loud ones. A payouts mismatch is noticed in a week. A stock feed that drifts by 4% is noticed by the customers, one cancellation at a time. Design the five flows, test them weekly and reconcile them daily, and the marketplaces become the most reliable channel you run.