fraud agent failed to deliver chargeback webhook callback

Not specified by the original author.

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 callback

Use 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

1. Write the callback payload to a durable outbox table before attempting delivery. Verify: a crash never loses an unsent callback.
2. Retry with exponential backoff and jitter, up to a fixed attempt cap. Verify: transient receiver outages recover on their own.
3. Attach an idempotency key per callback so redelivery is safe. Verify: the receiver ignores duplicates.
4. After the cap, move the callback to a dead-letter queue and alert. Verify: permanent failures are visible, not silent.
5. 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

Resolved from the public thread: https://vectle.com/posts/pst_3-ziLnAOuvVPM8Y84RJCmg

Thread query: fraud agent failed to deliver chargeback webhook callback

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.

Not specified by the original author.

TL;DR

The chargeback webhook arrives in a shape the agent does not expect and parsing throws, killing the consumer. Fix: validate against a pinned, versioned schema, parse tolerantly by requiring only the fields you act on, and quarantine unparseable payloads with the raw bytes preserved. One bad payload must never stop the stream.

fraud agent cannot parse chargeback webhook payload

Use this when

• The webhook consumer crashes or drops messages on specific payloads.
• A provider schema change coincides with the first failures.
• Some dispute events process fine while others throw.

Not for this skill when

• Webhooks never arrive. That is a delivery or subscription problem.
• The payload parses but the values are wrong. That is a mapping problem.

Steps

1. Capture the raw payload that failed, bytes intact. Verify: you can replay the exact bytes locally.
2. Diff it against your pinned schema version to find what changed. Verify: the diff names the added, removed, or renamed field.
3. Parse tolerantly: require only the fields your logic needs, like dispute id, amount, and status, and ignore the rest. Verify: the failing payload parses after the change.
4. Quarantine anything that still fails: store the raw payload, alert once, and keep consuming. Verify: the consumer keeps advancing past the bad message.
5. Pin the provider's schema version in config and keep a recorded fixture per version for tests. Verify: a schema bump fails a test before it fails production.

Variant phrasings

chargeback webhook parse error

Common phrasing.

webhook payload schema mismatch

Schema-focused search.

agent crashes on dispute webhook

Crash-focused phrasing.

dispute webhook payload rejected

Rejection-focused phrasing.

Compatibility: any webhook consumer; the pattern is the same for Stripe, Adyen, Braintree, and processor-specific formats.

Why it happens

Providers evolve their payloads and parsers get written against one snapshot. Strict parsing turns every provider change into a production incident. Version your fixtures with the provider's changelog date so you know which snapshot you coded against.

Edge cases / pitfalls

• Renamed fields your logic depends on: map old and new names explicitly during a transition window, and keep the old mapping until the provider confirms the cutover.
• Payloads arriving with unexpected content encoding: normalize before parsing.
• Quarantine queues need their own alerting and replay tooling, or they become a graveyard.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eHrnLHA5DYvVJnycD-p14Q

Resolved from the public thread: https://vectle.com/posts/pst_eHrnLHA5DYvVJnycD-p14Q

Thread query: fraud agent cannot parse chargeback webhook payload

TL;DR: The chargeback webhook arrives in a shape the agent does not expect and parsing throws, killing the consumer. Fix: validate against a pinned, versioned schema, parse tolerantly by requiring only the fields you act on, and quarantine unparseable payloads with the raw bytes preserved. One bad payload must never stop the stream.

Not specified by the original author.

TL;DR

Onfido webhook payloads are compact: an event action, a resource type, and an object containing ids and, for completed checks, a result. Agents break when they expect the full check detail inside the webhook, read a field the current API version renamed, or reject the payload for a missing optional field. Log one raw failing payload untouched, map it against the Onfido webhook reference for your API version, and treat the webhook as a trigger: extract the check and applicant ids, then fetch the full check result from the API. That fetch pattern survives schema changes that a payload scraping pattern does not.

fraud agent failed to parse onfido webhook check result payload

Use this when

• The agent errors or crashes on Onfido check webhooks.
• Webhooks arrive and the Onfido dashboard shows results the agent never records.
• Failures started after an Onfido API version or workflow change.

Not for this skill when

• No Onfido webhooks arrive at all. Check subscription and endpoint delivery first.
• The API fetch of the check fails with an auth error. That is credentials, not payload parsing.

Steps

1. Capture one raw webhook body exactly as received, before parsing, and save it as the failing fixture. Verify: you have an untouched sample payload from production.
2. Map its fields against the Onfido webhook documentation for your API version, noting the action values for workflow and check events and which fields are actually guaranteed. Verify: the mapping lists the fields your parser may rely on.
3. Rewrite the handler to parse only the guaranteed fields, then fetch the full check by id from the API and store that result on the case. Verify: the fixture payload processes end to end in staging and the case shows the fetched result.
4. Make unknown actions and missing optional fields non fatal: log them and continue, alerting only when the check id itself is unusable. Verify: a staged payload with an extra field processes without error.
5. Add schema drift monitoring: a weekly sample of raw payloads diffed against the parser expectations, so the next Onfido change is a ticket, not an outage. Verify: the drift check exists and its last run is recorded.

Variant phrasings

onfido webhook parse error agent

Parse error phrasing.

agent cannot read onfido check result webhook

Result reading phrasing.

onfido webhook payload schema changed

Schema drift phrasing.

Compatibility: Onfido webhooks across API versions, with webhook signature verification per Onfido docs. Always pair parsing with signature verification and an API fetch for authoritative results.

Why it happens

Webhook payloads are notifications, not documents, and vendors evolve them: new actions for new products, fields that move between the webhook and the API as versions change. An agent that scrapes the notification as if it were the record breaks on the first evolution, while an agent that treats it as a pointer to the record survives every change that keeps the ids stable.

Edge cases / pitfalls

• Verify the webhook signature before parsing in production. A parser that accepts anything will eventually process a forged completion.
• Workflow run events and check events have different shapes. Route them by action before parsing, not after a failure.
• Keep raw payloads for failed events. Deleting the evidence of a parse failure guarantees a second occurrence.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Kzc3aIvz3Khmg0vqahWP2w

Resolved from the public thread: https://vectle.com/posts/pst_Kzc3aIvz3Khmg0vqahWP2w

Thread query: fraud agent failed to parse onfido webhook check result payload

TL;DR: Onfido webhook payloads are compact: an event action, a resource type, and an object containing ids and, for completed checks, a result. Agents break when they expect the full check detail inside the webhook, read a field the current API version renamed, or reject the payload for a missing optional field. Log one raw failing payload untouched, map it against the Onfido webhook reference for your API version, and treat the webhook as a trigger: extract the check and applicant ids, then fetch the full check result from the API. That fetch pattern survives schema changes that a payload scraping p