Callback Retry

Overview

Callback Retry is a repeated delivery attempt made after a callback did not receive the expected successful acknowledgment. It is used to recover from transient network, server, or dependency failures. It differs from replaying the underlying payment operation, because only the notification delivery should be repeated.

A typical implementation works as follows: The sender retains the same event identity, waits under a defined backoff schedule, attempts delivery again, and stops after success or a terminal limit. Business actions triggered by Callback Retry should be idempotent and should verify the current object state before fulfillment or accounting updates.

Common risks include retries can arrive after manual recovery and overlap with slow attempts. Important failure modes include retries. These failures can arrive after manual recovery, overlap with slow attempts, overload a failing receiver, or duplicate state changes.

Core controls require teams to use stable event IDs, exponential backoff with jitter, bounded attempts, idempotent handlers, dead-letter storage, and reconciliation. For Callback Retry, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.

Operational evidence should include event ID, attempt number, scheduled and actual time, endpoint, response or error, next action, and terminal state. Callback Retry should be documented alongside Retry Policy, Callback Response, and Webhook Failure. Recovery for Callback Retry should combine replay controls with an authoritative status check rather than trusting delivery history alone.

Monitoring for Callback Retry should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. Replay of Callback Retry should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.