Duplicate Event

Overview

A Duplicate Event can appear when a provider retries a webhook after timeout, a queue redelivers an unacknowledged message, or a consumer restarts before committing its checkpoint. The same event ID and payload can therefore arrive more than once.

The condition differs from Duplicate Transaction . One payment can generate repeated notifications while remaining a single financial event. Treating every notification as new can create duplicate credit, fulfillment, email, or ledger posting.

Consumers should store stable provider event IDs or a canonical event key before applying side effects. If no stable ID exists, a carefully designed fingerprint can combine transaction, event type, version, and source sequence.

Repeated events should normally be acknowledged after Duplicate Suppression determines that the underlying effect was already applied. Silently rejecting them without a record can cause providers to continue retrying.

Monitoring should distinguish expected redelivery from abnormal event storms or inconsistent payloads under the same identifier. If a reused ID arrives with different data, the case should enter exception management rather than being suppressed automatically.

Event consumers should separate receipt from processing. The system can record the event first, then apply business logic in a controlled transaction and mark completion. If processing fails, the event remains retryable; if it was already completed, redelivery becomes harmless. This model also supports investigation when a provider says an event was delivered but the related payment state did not advance.

The raw repeated event should remain available for audit even when no side effect occurs. This proves that the delivery was received and intentionally deduplicated rather than lost.