Ecommerce ERP integration: scope the first reliable workflow

The storefront says an order is cancelled. The ERP still expects to ship it. Customer support approves a refund, but nobody can establish whether the payment provider accepted the request. The systems are online, but the order remains unresolved.

Scope the first integration to resolve that complete sequence. Start with one channel, a bounded product set and the relevant payment route. Define who can change each state, how the next system learns about it and what the team does when the handoff fails.

Shopify's integration guide describes connections across orders, inventory, product and financial records. Use those domains to choose a bounded workflow and assign ownership. Shopify ecommerce ERP integration.

Write the outcome before listing endpoints

A useful initial outcome might be:

For an agreed set of orders from one storefront, operations can trace accepted order lines through reservation, fulfilment or cancellation, payment and any refund. Finance can identify the records required for its approved accounting process. Every incomplete handoff has an owner.

Keep supplier feeds, additional channels and historical imports outside this first release unless the chosen lifecycle needs them.

Record what is deliberately outside the pilot. For example, preorder promises, split tenders and foreign-currency orders may need separate designs. Excluded cases must be detected and routed to the existing controlled process; they must not silently pass through an incomplete integration.

Assign authority at the action level

Naming the ERP the “source of truth” is insufficient if a warehouse confirms dispatch and a payment provider confirms a refund. Define the authority for each fact and which systems receive a copy.

Adapt these example assignments to the retailer's systems. One authority must control each reservation or refund decision.

Agree both identifiers and units. Order IDs need their source account or shop context. Quantities need a sellable-unit definition. Amounts need a currency and storage unit; rupees and paise cannot share an unexplained numeric column. Event timestamps need a timezone and a distinction between occurrence and ingestion.

The SKU-mapping guide gives a concrete example of why a channel line quantity may differ from the stock quantity to reserve.

Follow one order through a partial cancellation

Assume a customer pays ₹2,000 for a ₹1,200 shirt and an ₹800 mug. Ignore tax and fees for this operational example. The ERP reserves one unit of each. The customer then cancels the mug before it is picked; the shirt continues to dispatch.

At the end of the example, the remaining commercial value is ₹1,200. That arithmetic does not itself define the accounting entries or prove when the customer sees the refund. Those decisions remain attached to finance policy and provider evidence.

The cancellation has two independent consequences: a stock decision and a money decision. A successful reservation release does not prove the refund completed. Conversely, refund approval does not prove the parcel was stopped. Keep both visible.

1. Commerce orderCapture original lines, payment link and source identity.
2. Stock authorityAccept or reject each reservation.
3. Fulfilment decisionConfirm dispatch or the requested stop.
4. Money and accountingTrack authorised refunds and approved financial handoffs.

Stock exception

Cancellation arrives after pick: keep the unresolved fulfilment decision visible; release only what the current state permits.

Payment exception

Refund response is lost: recover the existing operation before allowing another financial action.

Both paths return to a reconciliation view that shows which business facts are confirmed and which still need action.

Design for an accepted write whose response was lost

A timeout leaves an important uncertainty: the receiving system may have applied the action before the response disappeared. Sending a new request with a new identity can create a second action.

Give each intended business operation a durable identity before sending it. Keep the operation's purpose, parameters, source event and recorded result. A retry must represent the same operation; a correction is a separately authorised change linked to the original.

Use the destination's documented idempotency or lookup capabilities where available. If the destination cannot distinguish a repeated request and there is no reliable way to determine whether it succeeded, retain an uncertain state and use a controlled recovery path. An internal duplicate check alone does not prove that an external write occurred only once.

Webhook handling requires a similar distinction between delivery and business effect. Shopify documents delivery verification and duplicate-delivery handling. The integration must also survive a crash between accepting an event and updating its destination, with a durable record of unfinished work. Shopify webhook verification.

At design review, ask engineering to explain how it prevents both “recorded as handled but never applied” and “applied but then repeated”. The implementation may use transactional records, a durable work queue and destination-side idempotency. Check the resulting business records in acceptance tests.

Keep recovery within the same authority rules

A recovery screen should not become an unrestricted write tool. Show the affected source record, current destination state, previous attempts and proposed action. Apply the same permissions and approval boundaries used in the normal flow.

Consider a late event that says the mug is reserved after a later event has already confirmed cancellation. Blindly applying events in arrival order can recreate a stale state. Use the provider's ordering/version contract or obtain current authoritative state where appropriate. Preserve the late event for diagnosis even when it should not change the business record.

Reconciliation is also needed for events that never arrived. A scheduled comparison can check the expected source orders against destination orders over a defined window. Use the source's current retrieval rules and pagination; a job that returns successfully after reading one page may still be incomplete.

For an illustrative batch of 100 distinct source orders, the reconciliation view might show:

• 97 applied and reconciled;
• two quarantined because their product mappings are unresolved;
• one with an uncertain destination-write outcome.

That accounts for all 100 orders, but only 97 have completed the intended path. Do not convert “accounted for” into “completed”. Keep the three outstanding orders assigned to an owner and prevent a retry from hiding their history.

Compare options against the same evidence

A native connector is a strong candidate when it covers the exact systems, record types and recovery requirements. Verify the supported versions, direction of updates, partial refunds, mappings, retry behaviour and operational ownership.

An integration platform may provide useful connectors, queues and monitoring. It still requires business-state definitions and tests. Its log saying “message delivered” may not establish that the ERP applied the intended transaction.

Custom engineering is justified by a demonstrated gap, such as a required reservation protocol or an unsupported exception lifecycle. The estimate should include support, schema changes, access management, reconciliation and incident recovery. A lower initial build estimate is incomplete if those obligations have no owner.

Give each supplier the same redacted order sequence and failure cases. Compare the resulting records and recovery steps.

Agree the acceptance and stop conditions

The business owner, engineering lead and finance representative should approve a test matrix before any production rollout.

Begin with read-only reconciliation or a shadow run where feasible, then enable a limited set of writes under agreed supervision. Set acceptable freshness and exception-age thresholds from the actual customer promise and operational capacity; this article does not prescribe a universal number.

Rollback also needs a business definition. Stopping the new integration does not undo a shipment or a refund. Agree how ownership returns to the existing process, how in-flight work is handed over and which corrections require approval. Keep previously accepted records available for reconciliation.

Make the first slice a repeatable operating process

The first integration is complete when the team can explain the normal flow, recognise an incomplete flow and recover it using the same controls. That provides a credible basis for adding another channel or workflow.

1. Select one lifecycle, its included cases and its explicit exclusions.
2. Assign authority for every consequential state change.
3. Build a representative example and a failure-test matrix before comparing implementation options.
4. Reconcile the pilot's source population and outcomes before expanding.
5. Assign ongoing owners for schema changes, exceptions and recovery.