Duplicate Callback

Overview

A Duplicate Callback is a repeated callback delivery that represents an event or business state already received by the destination. The term callback is broader than webhook, but in payment integrations both usually require the same duplicate-safe processing controls.

The main risks include double fulfillment, repeated ledger entries, duplicate notifications, repeated refunds, and inconsistent downstream side effects. Duplicates can result from retry policies, uncertain acknowledgements, network failures, or sender-side replay. Monitoring for Duplicate Callback should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events.

In production, teams should define ownership and apply stable event identifiers, payload fingerprints, idempotency records, atomic processing, acknowledgement after durable persistence, and retention rules. Business actions triggered by Duplicate Callback should be idempotent and should verify the current object state before fulfillment or accounting updates.

Useful measures include duplicate callback rate, deduplication hit rate, repeated-side-effect count, and acknowledgement latency. Duplicate Callback is closely connected to Duplicate Webhook, Webhook Deduplication, and Idempotent Consumer. Recovery for Duplicate Callback should combine replay controls with an authoritative status check rather than trusting delivery history alone.

A Duplicate Callback handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response. Replay of Duplicate Callback should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.

For Duplicate Callback, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Duplicate Callback.