fraud agent failed to deliver chargeback webhook callback
Makes chargeback webhook callbacks from a fraud agent reliable with a durable outbox, bounded retries, and a dead-letter queue. Use when callbacks to downstream systems fail silently or intermittently. Not for inbound webhook parsing.
TL;DR
A callback that fails once should not vanish. Write every callback to a durable outbox, retry with backoff, deduplicate on the receiving end with idempotency keys, and park permanent failures in a dead-letter queue with an alert.
fraud agent failed to deliver chargeback webhook callbackUse this when
- Callbacks to downstream systems fail silently or intermittently.
- A receiver outage means chargeback events never arrive.
- You cannot tell which callbacks were delivered and which were lost.
Not for this skill when
- Inbound webhooks fail to parse. That is a parsing problem.
- The receiver rejects the payload format. That is a contract problem.
- You need real-time delivery guarantees. Webhooks are at-least-once by nature.
Steps
- Write the callback payload to a durable outbox table before attempting delivery. Verify: a crash never loses an unsent callback.
- Retry with exponential backoff and jitter, up to a fixed attempt cap. Verify: transient receiver outages recover on their own.
- Attach an idempotency key per callback so redelivery is safe. Verify: the receiver ignores duplicates.
- After the cap, move the callback to a dead-letter queue and alert. Verify: permanent failures are visible, not silent.
- Reconcile the outbox against receiver logs daily. Verify: sent callbacks match received ones.
Variant phrasings
chargeback callback delivery failed
Same failure, common phrasing.
webhook callback not delivered by agent
Symptom-level search.
downstream chargeback notification lost
Impact-side wording.
Compatibility: Any downstream receiver of chargeback events. The outbox lives in the agent's own storage.
Why it happens
Agents often fire a callback inline and move on, so a receiver timeout or a crash between send and acknowledgement loses the event with no trace. Chargeback callbacks feed accounting and risk systems, so a lost one corrupts the ledger quietly and nobody notices until reconciliation.
Edge cases / pitfalls
- Unbounded retries turn a receiver outage into a self-inflicted load spike. Cap attempts.
- Idempotency keys must be stable across retries of the same callback, not regenerated per attempt.
- Dead-letter queues need an owner and a runbook, or they become a second silent drop.
- Order matters for chargeback state changes. Include a sequence number if the receiver applies them in order.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_3-ziLnAOuvVPM8Y84RJCmg