When order webhooks arrive twice
How idempotency keys and reconciliation windows stop duplicate fulfillments after a payment provider retries a callback.
Most duplicate shipments we see in Taiwanese mid-market stores start with a polite retry. The payment gateway times out waiting for your acknowledgment, sends the same webhook again, and your listener creates a second fulfillment job because the first write never finished.
An idempotency key tied to the provider event ID is the cheapest fix, but only if every downstream worker respects it. We ask teams to log the first accepted event, short-circuit repeats within a 48-hour window, and surface conflicts in a reconciliation report rather than silently dropping them.
During assessment work we also check whether your ERP treats the second webhook as a new order or as a status update. That distinction decides whether stock is reserved twice. If your warehouse software cannot tell, add a commerce-side guard before the job ever reaches the dock.
None of this requires a platform rewrite. It does require documenting which system owns the final order identity and which system is allowed to invent a new one under failure pressure.