When a webhook arrives late, the last payload received must not automatically win: the demonstrably newest order version should. Treat the webhook as a trigger, retrieve the current order from the source and compare modification times with the version already processed locally. This prevents delayed message delivery from reversing a newer payment status, address correction or note.
Arrival order is not modification order
Networks, retries and plugins do not guarantee that webhooks arrive in the order in which the customer or online store made the changes. Message B can arrive before message A even though A is older. A queue preserves only arrival order. Anyone blindly storing every payload as the new truth turns a transport delay into a business error.
Record at least three moments: when the source says the order changed, when the message arrived, and which source version has already been processed locally. Modification time determines the content; arrival time remains important for monitoring. If timing information is missing or unreliable, retrieving the order again is safer than guessing.
Freshness rules for order processing
- Use the store plus order ID as the identity, never just the visible order number.
- Retrieve the current source order after a grouping window if the API is available.
- Ignore content that is demonstrably older than the last source change processed.
- Keep the ignored event as an audit entry with the reason “outdated source version”.
- Do not automatically repeat all side effects when the modification time is unchanged.
- Send conflicting versions without a reliable clock for a controlled comparison.
These rules are more specific than general synchronisation. They belong at the order intake of an WooCommerce–AFAS integration, before transformation into a debtor, sales order or invoice.
Fictional example: the old address arrives last
Fictional example: at 14:20, customer Sara corrects her house number in order 6208. The update is processed immediately and the current order receives source modification time 14:20. Because of a retry, a webhook payload arrives at 14:24 that was created at 14:18 and contains the old house number.
The integration records the late message but sees that its source modification predates 14:20. It retrieves order 6208 again, confirms the new number and does not initiate an address change to AFAS or route planning. The order timeline states: “message received at 14:24; content skipped because the source version was older”. The employee can therefore explain why nothing happened. This fictional example also shows why “last received” alone is a dangerous definition of up to date.
Test the difficult edge cases
| Scenario | Desired decision |
|---|---|
| Older modification time, received later | Keep an audit record; do not apply the content |
| New modification time, same order | Retrieve the current order and process it with checks |
| Same time, identical content | No duplicate external actions |
| Clocks disagree | Read the source again or request manual attention |
| Source temporarily unavailable | Retry the read step; do not write a payload that may be outdated |
Show in Desk both the selected version and the reason another was skipped. This lets operations investigate an incident without raw logs. Meanwhile, the technical workflow in Connect remains repeatable: reading again is allowed, while a financial or logistical side effect starts only if the relevant state actually changed.
Pay attention to normalisation when comparing times. Online stores and external plugins may supply local time, UTC or text without a time zone. Convert values to one format on arrival and retain the original value for investigation. Do not substitute processing time for a missing modification time; that masks precisely the sequencing error you want to prevent. For critical fields, consider maintaining a monotonically increasing version or content hash. This lets you demonstrate that the address, payment status or line items actually changed. Test around daylight saving changes, network retries and a manual correction shortly after checkout. The acceptance test is not “the newest webhook won”, but “the data ultimately applied matches the latest valid state at the source”.
Always include both timelines in incident reports: the sequence of business changes and the technical order of arrival. This reveals whether the problem arose at the source, in transport or in processing. Without this distinction, a slow webhook can easily look like a mistake by the employee who entered the later correction.
Are delayed messages making your orders appear to revert? Ask Yindle to review the freshness rules in your order workflow.