Checkout Architecture
Part of Ecommerce platform integrations
Handling integration failures without losing orders
Detect a failed order feed, reconcile commerce and destination records, then replay missing work without duplicating actions.
When an order feed fails, use the commerce order to identify affected purchases and inspect each destination before retrying. A missing warehouse acknowledgement does not prove that no task was created. Hold uncertain orders from further downstream action until staff establish their payment and fulfilment state.
Find the affected orders
For each connection, make its last successful transfer, pending items, rejected items and subscription or job status visible to an operator. Give the alert an owner and a path to the original order.
Shopify documents webhook delivery failures and provides delivery metrics and logs. WooCommerce provides delivery logs and, by default, disables a webhook after more than five consecutive delivery failures. BigCommerce says a webhook subscription becomes deactivated after 90 days of inactivity. These mechanisms concern delivery; none proves that accounting or fulfilment processed an order.
Set an escalation window that fits the business's dispatch promise. Customer service should be able to distinguish an unpaid order, a paid order awaiting transfer and a paid order whose warehouse state is uncertain.
Platform-specific webhook failure handling
- Shopify
- Documents delivery metrics and logs; supports delivery verification via webhook ID.
- WooCommerce
- Disables webhooks after five consecutive delivery failures by default.
- BigCommerce
- Deactivates webhook subscriptions after 90 days of inactivity.
Integration failure thresholds by platform
- WooCommerce retry limit
- 5 consecutive failures
- BigCommerce subscription deactivation
- After 90 days of inactivity
- Shopify delivery verification
- Supported via webhook ID
Reconcile before replay
List commerce orders for the affected period and compare them with destination records using the original order ID. Check payment status and any existing warehouse or accounting entry before deciding what to resend.
| Finding | Next check |
|---|---|
| No destination record | Was the order eligible, and did another route receive it? |
| Record exists but acknowledgement failed | Can staff link it to the commerce order and confirm its state? |
| Records differ | Which system owns the changed field, and is an amendment permitted? |
| Two destination records exist | Which has been acted on, and who resolves the other? |
Use an event or transfer ID to detect repeat deliveries, and a stable order or destination-action key to prevent a repeated delivery from creating a second pick task or financial entry. Shopify documents using the webhook ID to detect duplicate deliveries. Apply idempotent handling so duplicate deliveries do not repeat destination actions; duplicate deliveries can occur. Hiding a duplicate notification in a log is insufficient if the destination action has already happened.
Restore the flow
Fix the cause, such as an unavailable endpoint, rejected field or expired connection. Confirm that the subscription or scheduled job is active. Replay only records whose eligibility and destination state are known. Where updates may arrive out of order, use a controlled current-state update or apply changes in their correct sequence.
After replay, compare eligible commerce orders, destination records and unresolved exceptions for the affected period. Inspect item quantities, addresses and payment states in the affected records. If an order has already shipped, resolve a discrepancy with the responsible team instead of overwriting a completed action.
Record the first affected order, recovery period, actions taken, remaining exceptions and owner. Base customer messages on verified order states.
