Refund Callback
Pronunciation: REE-fund KAWL-bak
Definition
A refund callback is an asynchronous server-to-server notification reporting a change in a refund request’s processing or settlement status. Refund Callback must specify the producer, consumer, event type and version, delivery URL, stable event identifier, signature method, timestamp, retry policy, and expected response. A reliable Refund Callback implementation validates authenticity, acknowledges quickly, stores the event durably, processes idempotently, tolerates duplicates and reordering, and records the final business outcome.
Overview
A refund callback is an asynchronous server-to-server notification reporting a change in a refund request’s processing or settlement status. Durable processing, status queries, replay tools, and reconciliation should resolve remaining delivery gaps across systems. Marking a refund settled from an unauthenticated event can create financial misstatement. Applications use the event to update orders, customer communication, support tools, and accounting workflows. A callback may also describe provider completion before a bank, network, or blockchain reaches the merchant’s desired finality. Monitoring for Refund Callback should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. The Refund Callback path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state.
Receivers should verify authenticity, validate refund and original-payment identity, compare amount and currency, deduplicate atomically, and enforce legal state transitions. The provider may notify the merchant when a refund is accepted, processing, completed, failed, rejected, or canceled. The production contract for Refund Callback should state the supported event identifiers, payloads, signatures, endpoints, attempts, acknowledgements, and processing outcomes, required and optional fields, types and units, validation rules, state preconditions, version, permissions, limits, errors, and compatibility guarantees. Callbacks can be forged, duplicated, delayed, or delivered out of order. Business actions triggered by Refund Callback should be idempotent and should verify the current object state before fulfillment or accounting updates.
Customer-facing wording must reflect the actual settlement stage.
Recovery for Refund Callback should combine replay controls with an authoritative status check rather than trusting delivery history alone.
A Refund Callback handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.
Key Takeaway
Refund callbacks require authentication, idempotency, amount validation, state control, settlement-aware wording, replay, and reconciliation.
Sources
- IETF RFC 9110 — IETF (2026-07-30)
- OpenAPI Initiative Documentation: V3.2.0 — OpenAPI Initiative (2026-07-30)
- OxaPay Documentation: Webhook — OxaPay (2026-07-30)