Define the marketplace you are connecting
Marketplace integration software can mean importing orders from an external marketplace or connecting sellers to a marketplace you operate. Those projects have different owners. An aggregator connector receives someone else’s channel orders; an owned marketplace must define seller onboarding, catalog rights, customer checkout, fulfillment and financial responsibilities.
Start with one seller, one product and one order. List every system that creates or changes its records. Buying middleware does not decide which catalog, inventory balance or financial record is authoritative.
Map the catalog and stock flow
Use this as a proposed flow to confirm with your systems, rather than a promise that every connector performs each step.
Seller / ERP → Mapping and validation → Marketplace catalog → Customer channel Stock owner → Availability update → Orderable quantity Rejected update → Exception queue → Integration owner
Agree seller and store identifiers, product IDs, variants, required options, price, currency, taxes and available quantity. Decide whether stock means physical units, units available to sell or a simple product-availability switch. Recipe ingredients, reserved inventory and warehouse stock are different records.
Name the source for each field and define update frequency, stale-data behavior and conflict resolution. A POS that owns price need not own product photography; an ERP stock count does not prove that an order reservation has reached it.
Separate the order from payment and settlement
Customer checkout → Order record → Seller acceptance → Fulfillment Payment provider → Payment result → Order payment reference Order / refund records → ERP reconciliation Seller settlement → Payment arrangement and agreed payout records
A successful payment is not proof of seller acceptance, stock deduction or ERP posting. Identify who creates the order reference, when inventory is reserved, who changes fulfillment state and how cancellation affects each system. Preserve external references for investigation.
For multiple sellers, define commissions, fees, refund allocation and payout responsibility with the payment provider and commercial agreement. A single customer checkout does not establish the settlement setup, and an order-status webhook is not a payout confirmation.
Choose the connection and assign each failure
The Ordering.co API exposes documented ordering resources for authorized applications. Webhooks send configured events to endpoints you operate. Use the documented operation, authentication and payload for each required resource; do not infer arbitrary ERP object support from API availability.
A direct connector may suit one supported POS flow. Middleware can add another supported route, with another credential, mapping and support boundary. Custom development needs an owner for implementation and ongoing changes. Review the POS directory and middleware options for the actual product and version.
Assign catalog rejection to the data owner, authentication failure to the authorized account owner, delivery failure to the integration operator and financial mismatch to reconciliation staff. Keep an order visible to operations while the technical owner resolves its connector exception.
Design recovery before turning on traffic
Specify repeated-message handling, stable identifiers, retries, alerts and a place to inspect failed work. If a receiver acknowledges an event before finishing ERP work, record the intermediate state and who retries it. Avoid replaying a payment or creating another order merely because a request timed out.
Test one valid update, one invalid product, a repeated event, a disconnected receiver, an out-of-order status and a partial refund. Compare source and destination records after recovery. A successful request or enabled connector is only one piece of that evidence.
Price and pilot the complete integration
Compare setup, licenses, API access, per-store or volume charges, monitoring, support and future schema changes. An absent vendor rate is unquoted. Give one team ownership of a cross-system incident so the seller is not left managing several support tickets.
Pilot one seller through catalog publication, stock change, paid order, acceptance, fulfillment and refund, then reconcile with the ERP. Expand only after you can trace the records and recover failures. Explore Ordering.co marketplace solutions and book a demo with your seller model, ERP, current POS and a sample transaction.