A Shopify integration needs to do more than move an order successfully. It needs to recognise an order it has already processed, avoid publishing stale availability and preserve the relationship between a refund and the financial record it changes. These controls are especially important when several systems share the order lifecycle.
The examples here are illustrative engineering checks. They contain no customer data or measured client outcomes. The correct implementation depends on your connector, ERP configuration and agreed operating rules.
Start with a record ownership map
Identify the owner of each product field, inventory calculation, order state and financial action. Keep product, variant and location references stable across systems. Record whether a change is an instruction to another system or a notification of something already completed.
Define the lifecycle from checkout through ERP acceptance, fulfilment, payment, cancellation and refund. A status called complete can mean different things in different systems. Map the business meaning and allowed transitions rather than copying labels without interpretation.
Prevent duplicate orders at the business boundary
Shopify documents that webhook deliveries can repeat. It also does not guarantee ordering. A receiver should validate the delivery, handle duplicates and reconcile missed work. A webhook delivery identifier and the underlying business order reference serve different purposes.
Record a durable order reference that includes the source shop where needed. Before creating a destination transaction after an uncertain result, determine whether that business operation already succeeded. Persist the relationship between the source order and destination transaction so recovery can reuse it.
A check followed by a create can still race if parallel workers handle the same order. Use the uniqueness or atomic processing mechanism available in your implementation. If the connector cannot provide the required guarantee, identify that limitation and agree a controlled recovery method.
Illustrative acceptance check: interrupt the acknowledgement after a destination write and replay the same operation. Confirm that the original transaction is recognised and no additional order is created. Also test concurrent deliveries and an update arriving before a create notification.
Explain inventory drift before increasing frequency
Agree what available stock means: physical stock, reservations, stock status, buffers and location eligibility may all affect the value. Increasing sync frequency cannot correct a wrong calculation or competing ownership.
For the Business Central Shopify connector, Microsoft documents location mappings and stock calculation settings. Validate these against the intended fulfilment process. Do not assume that all source locations should contribute to every Shopify location.
Check for competing writers. An ERP feed, an application and manual edits can each change the same destination value. Record which system may make each change and how a later update is evaluated. Monitor freshness and reconciliation differences, not only successful API responses.
Illustrative acceptance check: change an approved source quantity while a prior update is delayed. Verify that processing the delayed update cannot restore an obsolete value. Test a missing location mapping and a source outage, including what the storefront is permitted to promise while data is stale.
Keep refunds separate from stock and settlement
A return request, a payment refund, an ERP credit and a restock are different events. Decide which event authorises each action and which reference links them. A refund does not automatically mean goods have been returned or made available for sale.
Preserve the original transaction reference, refunded lines, relevant tax treatment and the destination credit or payment reference. Handle partial and repeated requests explicitly. Check whether an integration retry could issue another refund or create another credit.
Reconcile payment settlements separately from orders. Fees, timing differences, adjustments and refunds can explain why an order total differs from a bank deposit. Finance should agree the reconciliation basis and exception process.
Reconcile records as well as totals
Define the expected source population for a consistent cutoff and compare it with destination records by stable identifiers. Totals alone can hide a missing record and an unrelated duplicate of the same value. Investigate unmatched references and unexpected status differences.
Keep reconciliation jobs separate from the assumption that every event arrived. Record the last successful check, the age of unresolved exceptions and who owns them. A dashboard should distinguish an active failure from work that is waiting for a business decision.
Recover without creating a second incident
Preserve the available evidence, identify the affected population and decide whether the current source state or the original event should drive recovery. Test a controlled replay before widening it. Confirm destination side effects such as reservations, emails and postings.
Keep a recovery log with the reason, approval, source references and observed result. Do not close the incident merely because the integration run is green. Confirm that the business records reconcile and that someone owns any remaining exception.
Make the support boundary explicit
A support plan should cover the named connector or flows, environments, access, monitoring, response arrangements and escalation. Specify who handles platform outages, ERP configuration and custom code. Bring recurring data issues back to their source owner rather than repeatedly correcting the destination.
For a new connection, use the same checks as acceptance criteria before launch. For an existing connection, start with the failure that affects customers or finance and preserve evidence before changing the configuration.
Explore Shopify integration services in Australia
Read the Shopify and NetSuite integration guide
Further reading
Shopify: webhook delivery verification and duplicate handling