Reliable Webhook Integration for Orders and Inventory

An order appears in the store but never reaches the ERP. A repeated payment notification creates a second operation. A delayed stock update leaves staff unsure which screen to trust. These failures often concern how the integration behaves when something goes wrong, rather than whether a connection exists.

A webhook sends a notification when an event occurs. A reliable integration also defines what happens when that notification is repeated, delayed or cannot be processed. This guide uses a hypothetical order and inventory workflow to explain the decisions involved.

What is a webhook?

An API lets your application request information or an operation. A webhook notifies an address you provide when a particular event occurs. Instead of repeatedly asking whether a payment has arrived, your application receives the event. Stripe’s webhook documentation explains this delivery model.

The methods work together: a notification can trigger an API request for the current order state. For the broader context, read our guide to APIs in business.

Delivery and business completion are separate

A successful HTTP response from your endpoint does not prove that an order was correctly processed in the ERP. Receipt, durable acceptance and the business result are different stages.

Our suggested flow is to verify the notification, persist it in an incoming-event record or durable queue, and then process it. Return a successful delivery response after durable acceptance, within the provider’s response deadline. A temporary queue or an acknowledgement sent after a failed write can turn “we will process it later” into lost work.

Link the event identifier, account, source system, processing status and business order number. Support staff should be able to locate the failed stage using an order number, without searching unrelated technical logs.

What happens when the event arrives twice?

Repeated delivery should be an expected scenario. Stripe explicitly documents that event ordering is not guaranteed and that an endpoint can receive the same event again. Track event identifiers rather than assuming each delivery represents new work. See its ordering and duplicate-delivery guidance.

An idempotent operation avoids an unintended additional result when the same work is requested again. The gap between recording an event and changing an order matters too. Where possible, handle deduplication and the local business change in one database transaction.

External shipping or invoicing calls require a separate assessment of the receiving system’s idempotency support and status-query capabilities. A local “processed” flag does not provide an end-to-end guarantee that every external effect happens exactly once.

Verify the sender and the business transition

An order number in a payload is not sufficient proof of origin. Implement the provider’s signature verification correctly. For example, Shopify’s delivery-verification guide describes HMAC verification using the raw request body. Header names and methods differ across providers.

A valid signature does not authorize every business operation. Check that the notification belongs to the expected store, matches an allowed event type and represents a valid order transition. An old notification should not move a cancelled order back to a prepared state.

Where a provider does not supply a usable version or sequence, consider retrieving the current source state and applying explicit transition rules. An arrival timestamp alone is not a universal ordering strategy.

Plan retries, failure handling and reconciliation

A temporary connection failure and an invalid product code should not follow the same recovery path. Classify retryable failures and set both delays and attempt limits. Microsoft’s Retry pattern discusses transient failures and the need to consider whether an operation can safely be repeated.

Exhausted jobs should appear in an actionable failure list. An authorized operator needs a recorded way to replay them. Reconcile with the source periodically as well: ask whether every source order has the correct target state, not only whether a notification was received.

If your own system updates a database and then publishes an event, consider the consistency gap between those writes. AWS’s transactional outbox guidance describes that dual-write problem.

Acceptance checks before launch

Scenario	Expected result
Deliver the same event twice	No extra order or inventory deduction
Deliver an old event after a new one	Valid business state does not move backwards
Fail the queue write	The event is not silently acknowledged as accepted
Take the ERP temporarily offline	Work remains traceable and is retried appropriately
Send an invalid signature	No business operation executes
Remove a target order from the test workflow	Reconciliation detects the mismatch

Add these checks to your integration project’s acceptance criteria. A useful specification names the systems involved and assigns ownership for failures, alerts, replays and maintenance.

Contact Lumethis to review an order, inventory or payment workflow. We can scope integration and custom software services around your existing systems.

Technical sources checked on November 1, 2026. Confirm each provider’s current delivery and retry rules when implementing its integration.