fraud agent double-counted duplicate transaction events and failed

Not specified by the original author.

TL;DR

The event stream delivers duplicates, at-least-once is the norm, and the agent counts every delivery as a new transaction. Dedupe on the event id before any counting, and make the ledger check tolerant of replays. Velocity and amount features must count unique events, never raw deliveries, or every retry storm looks like a fraud wave.

fraud agent double-counted duplicate transaction events and failed

Use this when

• Velocity features spike without real volume growth.
• Ledger checks fail on totals that do not reconcile.
• Retried webhooks or replays inflate counts.

Not for this skill when

• Duplicates are distinct transactions that look alike. Check the event ids first.
• The count is wrong for one transaction. That is a parsing problem.

Steps

1. Dedupe at ingestion on the provider event id, before any feature computation. Verify: replaying the same event file twice changes no feature and emits no new alert.
2. Store processed event ids with a TTL longer than the max replay window. Verify: a replay from last week is still caught.
3. Make the ledger check replay-aware: reconcile on unique events, and log duplicates separately. Verify: the ledger passes with duplicates in the stream and flags the duplicate share in its report.
4. Monitor the duplicate rate itself: a sudden jump means an upstream retry storm. Verify: a dashboard shows duplicate share over time with an alert on sudden jumps.

Variant phrasings

duplicate events double counted

Ingestion phrasing.

at-least-once delivery inflating velocity

Semantics phrasing.

replayed webhooks broke ledger check

Replay phrasing.

Compatibility: Works with any event source that emits stable event ids. The dedupe store can be any key-value store with TTL, sized to the replay window.

Why it happens

Pipelines promise at-least-once delivery and the agent was written as if delivery meant exactly-once. Every retry, replay, and redelivery becomes a phantom transaction in the features, and the ledger can never reconcile.

Edge cases / pitfalls

• TTL too short misses slow replays. Size it to the longest upstream retry window.
• Some providers reuse event ids across event types. Key on id plus type.
• Dedupe at ingestion only, not at every stage, or you pay the cost repeatedly.
• Backfills look like duplicates. Whitelist backfill runs explicitly so they are not quarantined.

Provenance

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

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

Thread query: fraud agent double-counted duplicate transaction events and failed

TL;DR: The event stream delivers duplicates, at-least-once is the norm, and the agent counts every delivery as a new transaction. Dedupe on the event id before any counting, and make the ledger check tolerant of replays. Velocity and amount features must count unique events, never raw deliveries, or every retry storm looks like a fraud wave.

Not specified by the original author.

TL;DR

Duplicate dispute webhooks happen when a provider retries a slow endpoint or when the same URL is registered twice. Dedupe on your side by event id in a persistent store, return 200 fast, and check the dashboard for doubly-registered endpoints.

duplicate dispute webhooks firing twice: how to fix

Use this when

• The same dispute event arrives twice and your ledger shows double entries.
• Duplicates appear on every event, not just one.
• The second copy arrives seconds or minutes after the first.

Not for this skill when

• Events never arrive. That is a subscription problem.
• Events arrive but in the wrong order. That is an ordering problem.

Steps

1. Log every incoming event id with its arrival timestamp. Verify: you can see pairs of identical ids in the log.
2. Add an event-id dedupe store (a table or cache with a unique key) and skip any id already processed. Verify: a replayed event is acknowledged but not reprocessed.
3. Make your handler acknowledge quickly and do heavy work asynchronously. Verify: the endpoint responds 200 well under the provider's timeout.
4. Check the dashboard for the same URL registered twice or overlapping event subscriptions. Verify: each event type has exactly one live endpoint.
5. Backfill your ledger by collapsing rows with duplicate event ids, keeping the earliest. Verify: totals match the provider's dispute list.

Variant phrasings

dispute webhook delivered twice

Common phrasing.

stripe webhook duplicate dispute event

Provider-specific search.

webhook event id dedupe disputes

Solution-wording search.

Compatibility: Any webhook provider that retries on slow or failed acknowledgements. Event ids are unique per event across Stripe, Adyen, and similar providers.

Why it happens

Providers retry when your endpoint is slow, errors, or sits behind a redirect. Each retry is a full redelivery. Separately, teams often register the same URL twice during migrations and each registration gets its own copy. Both look identical from your side.

Edge cases / pitfalls

• Dedupe on event id, not on payload hash. Retries can carry slightly different timestamps.
• Keep dedupe records for at least the provider's retry window, longer if you replay events.
• A 200 after partial processing is worse than a 500. Acknowledge only when the event is safely stored.
• During incident replays, expect duplicates by design. Keep the dedupe on.

Provenance

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

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

Thread query: duplicate dispute webhooks firing twice: how to fix

TL;DR: Duplicate dispute webhooks happen when a provider retries a slow endpoint or when the same URL is registered twice. Dedupe on your side by event id in a persistent store, return 200 fast, and check the dashboard for doubly-registered endpoints.

Not specified by the original author.

TL;DR

The agent re-flags the same transaction because it has no memory of what it already flagged. Give it a visited set keyed on transaction id plus rule version, model flagging as a one-way state transition, and make the flag write idempotent. One pass should produce exactly one flag event.

fraud agent loop detected: re-flagging the same transaction

Use this when

• Logs show the same transaction id flagged two or more times in one run.
• Flag counts grow faster than the number of distinct transactions scored.
• The loop clears on restart and then starts again from scratch.

Not for this skill when

• A rule engine fires on genuinely new transactions. That is rule tuning, not a loop.
• The queue grows because transaction volume grew. Check ingress before blaming the agent.

Steps

1. Confirm the loop: search run logs for repeated transaction ids inside one run id. Verify: one id appears three or more times under the same rule version.
2. Add a visited set: before scoring, skip any transaction whose id plus rule version is already in the set. Verify: re-running the batch flags zero already-seen transactions.
3. Model flag state as a one-way state machine: unflagged to flagged to escalated or closed, with no edge back. Verify: a flagged transaction can only move forward.
4. Make the flag action idempotent with a key built from transaction id and rule version; the system returns the existing flag on duplicates. Verify: a double POST returns the same flag id with no new row.
5. Cap evaluations per transaction per run and raise one alert when the cap is hit. Verify: a run that hits the cap raises the alert exactly once and moves on.

Variant phrasings

fraud agent keeps flagging the same transaction

Same loop, looser phrasing.

agent flags transaction twice

Duplicate-flag symptom search.

reflagging loop in fraud review

Loop-focused phrasing.

Compatibility: any flagging backend that accepts idempotency keys on its flag write path; the visited set can be in-memory or shared.

Why it happens

The evaluation loop treats every cycle as a fresh look with no memory. Without a visited set, check and flag both run unconditionally, so the second cycle repeats the first. Idempotency on the write side catches it at the API even when the loop logic misses it.

Edge cases / pitfalls

• Rule version changes are legitimate re-scores: include the version in the visited key so a new rule still gets one clean pass.
• Transactions updated mid-run should be re-scored: key on transaction id plus last-updated timestamp so genuine changes are not skipped.
• Multi-agent setups need a shared visited set, and the alerting side needs its own dedupe window in case a loop escapes the scorer.

Provenance

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

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

Thread query: fraud agent loop detected: re-flagging the same transaction

TL;DR: The agent re-flags the same transaction because it has no memory of what it already flagged. Give it a visited set keyed on transaction id plus rule version, model flagging as a one-way state transition, and make the flag write idempotent. One pass should produce exactly one flag event.