fraud agent hallucinated a dispute id that does not exist

Not specified by the original author.

TL;DR

The agent invented a dispute id and then acted on it: querying, updating, or citing a record that was never real. Fix: treat every model-generated id as untrusted. Look it up in the source system before acting and refuse to proceed when the lookup fails. Lookup-then-act is the whole fix.

fraud agent hallucinated a dispute id that does not exist

Use this when

• Actions reference dispute ids the provider has no record of.
• Citations in agent output point at disputes that do not exist.
• Updates fail with not-found errors on ids the agent produced.

Not for this skill when

• A real id fails lookup during a provider outage. That is availability, not hallucination.
• The id exists but under a different merchant. That is a scoping bug.

Steps

1. Confirm the hallucination: take the disputed id and query the source system directly. Verify: the system returns not found for the id.
2. Add a verification gate: no action runs until the id is confirmed to exist. Verify: a fake id is rejected at the gate with a logged reason.
3. Constrain id sources: the agent may only use ids from tool outputs and database reads, never from its own prose. Verify: ids travel as structured fields, not parsed from sentences.
4. Log every id the agent acts on together with its source. Verify: an auditor can trace each id back to the system that issued it.
5. Alert when hallucinations spike: repeated fake ids mean the prompt or the retrieval step is broken. Verify: the alert fires before bad actions accumulate.

Variant phrasings

agent invented dispute id

Common phrasing.

fake dispute id hallucination

Hallucination-focused search.

dispute id does not exist

Lookup-focused phrasing.

hallucinated dispute identifier

Identifier-focused phrasing.

Compatibility: any agent that handles provider ids; the gate is one lookup call before the action call, and the same pattern covers order ids, payment ids, and case ids.

Why it happens

Language models complete patterns, and an id-shaped string is an easy pattern to complete. Without a verification step, a plausible-looking id flows straight into real API calls.

Edge cases / pitfalls

• Ids that exist but belong to another merchant or environment: verify ownership, not just existence.
• Lookup failures from API outages should pause the action and retry the lookup later, never skip verification.
• Never let the agent fix a bad id by guessing a similar one. Reject it and re-derive from the source.

Provenance

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

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

Thread query: fraud agent hallucinated a dispute id that does not exist

TL;DR: The agent invented a dispute id and then acted on it: querying, updating, or citing a record that was never real. Fix: treat every model-generated id as untrusted. Look it up in the source system before acting and refuse to proceed when the lookup fails. Lookup-then-act is the whole fix.

Not specified by the original author.

TL;DR

An empty Braintree dispute search usually means the query is over-filtered or pointed at the wrong environment. Drop the status and date filters, confirm you are searching production with production credentials, and page through the results.

braintree dispute search returns empty for open disputes: how to fix

Use this when

• You know open disputes exist but search returns nothing.
• Search worked before a code or credential change.
• One environment finds disputes and the other does not.

Not for this skill when

• Webhooks about disputes are missing. That is a delivery issue.
• Evidence submission fails. That is a different call.

Steps

1. Run the search with no filters at all and confirm disputes come back. Verify: the unfiltered search returns at least the disputes you know about.
2. Re-add filters one at a time, starting with status, and note which filter empties the results. Verify: you can name the exact filter that breaks it.
3. Check the status values against the current list Braintree documents; statuses get renamed. Verify: your filter uses a status that exists today.
4. Confirm the API credential points at production, not sandbox, and that the merchant account matches. Verify: a known production dispute id is retrievable by id.
5. Page through results instead of trusting the first page. Verify: the total count matches what the control panel shows.

Variant phrasings

braintree dispute search no results

Shortest form.

braintree find open disputes empty

Method-wording search.

braintree dispute query returns nothing

Symptom phrasing.

Compatibility: Braintree dispute search API. Status values and search fields follow Braintree's current reference; sandbox and production are fully separate.

Why it happens

Dispute statuses are an enum that changes over the years, and code written against an old list silently filters everything out. The other half of cases are environment mixups: sandbox credentials querying an empty sandbox while the real disputes sit in production.

Edge cases / pitfalls

• Date filters with the wrong time zone can exclude everything. Check whether the API expects UTC.
• Text search on dispute fields is loose. Prefer structured filters over free text.
• A search that worked last month can break on a status rename. Diff your filter list against the docs yearly.
• Control panel counts and API counts should agree. If they do not, suspect the merchant account id.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eJAcrbX-1-rkFrKucXizJw

Resolved from the public thread: https://vectle.com/posts/pst_eJAcrbX-1-rkFrKucXizJw

Thread query: braintree dispute search returns empty for open disputes: how to fix

TL;DR: An empty Braintree dispute search usually means the query is over-filtered or pointed at the wrong environment. Drop the status and date filters, confirm you are searching production with production credentials, and page through the results.

Not specified by the original author.

TL;DR

Evidence pulls hit Stripe's limits because the agent fetches everything at once. Prioritize disputes by evidence deadline, back off with jitter on 429, cache what you fetch, and checkpoint per dispute id so the run resumes where it stopped.

fraud agent failed to pull dispute evidence after stripe api rate limit

Use this when

• Evidence pulls 429 mid-run.
• The agent fetches disputes in arrival order and the urgent ones starve.
• A crashed run re-fetches every dispute from the start.

Not for this skill when

• The dispute is closed. Evidence submission is rejected regardless of pacing.
• Evidence is missing on your side. That is a data problem, not a limit problem.
• Stripe is down. That is an outage, not throttling.

Steps

1. Sort the dispute queue by evidence deadline, soonest first. Verify: the most urgent disputes are fetched before any limit is hit.
2. Add jittered exponential backoff on 429, honoring any retry guidance in the response. Verify: the agent slows down instead of hammering.
3. Cache dispute and evidence objects for the run. Never re-fetch a dispute already pulled. Verify: each dispute id hits the API once.
4. Checkpoint after each dispute completes. Verify: a crash resumes at the next dispute, not the first.
5. If limits persist, split the run across time or request a limit review. Verify: the queue drains without repeated 429s.

Variant phrasings

stripe 429 pulling dispute evidence

Same failure, common phrasing.

agent rate limited on disputes api

Symptom-level search.

dispute evidence fetch throttled

Engineering-side wording.

Compatibility: Stripe Disputes API. Rate limits are per account and per endpoint family.

Why it happens

Dispute evidence pulls are heavy: each dispute means the dispute object, its evidence, and often the original charge. An agent looping that per dispute with no pacing burns through the quota fast, and evidence deadlines do not move, so the 429s land hardest on the most urgent items when they are fetched last.

Edge cases / pitfalls

• Evidence deadlines are hard. A 429 retry loop that outlasts a deadline loses the dispute automatically, so build the deadline into fetch priority.
• Closed disputes reject evidence submissions. Check status before fetching.
• Paginating evidence lists counts against the same quota. Fetch only what you will submit.
• Keep the evidence assembly idempotent so a resumed run does not submit duplicates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zhM31q7ahaNxygxR-Qae-A

Resolved from the public thread: https://vectle.com/posts/pst_zhM31q7ahaNxygxR-Qae-A

Thread query: fraud agent failed to pull dispute evidence after stripe api rate limit

TL;DR: Evidence pulls hit Stripe's limits because the agent fetches everything at once. Prioritize disputes by evidence deadline, back off with jitter on 429, cache what you fetch, and checkpoint per dispute id so the run resumes where it stopped.