Delayed Webhook

Overview

A Delayed Webhook is an event notification that reaches the receiver later than the delivery time expected by the sender or the business workflow. It is not the same as a failed webhook because the event may eventually arrive successfully, and it is not proof that the underlying payment action was delayed.

The main risks include premature fulfillment decisions, stale customer status, duplicate recovery work, out-of-order processing, and false incident escalation. Delay can occur before dispatch, in a retry queue, across the network, or inside the receiving system.

In production, teams should define ownership and apply event timestamps, delivery-attempt timestamps, queue-age monitoring, idempotent consumers, status-query fallback, and service-level thresholds. A Delayed Webhook handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.

Useful measures include end-to-end webhook latency, queue age, delayed-event rate, p95 delivery time, and status-query fallback volume. Delayed Webhook is closely connected to Failed Webhook, Webhook Event Log, and Out-of-Order Payment Event. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Delayed Webhook.

Business actions triggered by Delayed Webhook should be idempotent and should verify the current object state before fulfillment or accounting updates.

Monitoring for Delayed Webhook should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. Replay of Delayed Webhook should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event. For Delayed Webhook, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.