Duplicate Callback

Overview

Context and purpose

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. 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 . A Duplicate Callback handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.

How it works

A duplicate callback is a repeated delivery representing the same event or logical transition. At-least-once delivery and retry after missing acknowledgment make duplicates normal rather than exceptional.

Practical checks and failure points

Store event identity and processed status transactionally with the resulting business action. Do not deduplicate solely by amount or customer name.

Related concepts

Payment Event Delivery · API Response