fraud agent failed to close reopened disputes and looped

Not specified by the original author.

TL;DR

The agent keeps closing a dispute that keeps reopening because it never reads the current status and has no reopen limit. Fix: fetch the live status first and only close from a closeable state, make the close idempotent, count reopens, and after three reopens hand the case to a human with the full timeline. A reopen is usually new information, not a failed close.

fraud agent failed to close reopened disputes and looped

Use this when

• The same dispute id cycles between closed and open across agent runs.
• Close-call volume for one dispute grows without the dispute staying closed.
• Analysts report the agent fighting their manual reopens.

Not for this skill when

• A dispute reopens once because new evidence arrived. That is the system working.
• The dispute never closes because the provider API errors. That is a different failure.

Steps

1. Fetch the live dispute status before every close attempt. Verify: the close call only fires when the status is open or under review, never when already closed.
2. Make the close idempotent with a client-generated key built from dispute id and attempt number. Verify: two close calls for the same attempt produce one close event.
3. Track a reopen counter per dispute, incremented on each closed-to-open transition. Verify: the counter matches the transitions in the event log.
4. Set a reopen ceiling of three. Past it, stop closing and create an analyst task with the timeline attached. Verify: the fourth reopen creates a task, not another close call.
5. Log every status transition with timestamp and actor. Verify: an auditor can replay the full close and reopen sequence.

Variant phrasings

dispute reopened after close agent loops

Reopen-focused phrasing.

agent cannot close dispute keeps reopening

Symptom-level search.

reopened dispute close loop

Short loop phrasing.

Compatibility: Stripe, Adyen, and Braintree dispute APIs expose a status field and accept idempotency keys on writes; the pattern ports across providers.

Why it happens

The agent's plan says "close the dispute" and it retries the plan on failure. But a reopen is not a failed close, it is a new state, often from new evidence or a buyer filing again. Without reading state first and counting reopens, the agent fights the state machine forever.

Edge cases / pitfalls

• A reopen with new evidence deserves a fresh review cycle, not a loop guard trip. Check the evidence delta before counting it.
• Idempotency keys scoped too broadly swallow legitimate retries; scope the key per close attempt.
• Some providers reopen disputes spuriously; the ceiling still applies, escalate and let a human confirm.
• Prefer provider webhooks for status changes over polling; polling burns rate limits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_djuag9PYawvi01D98Eqx-w

Resolved from the public thread: https://vectle.com/posts/pst_djuag9PYawvi01D98Eqx-w

Thread query: fraud agent failed to close reopened disputes and looped

TL;DR: The agent keeps closing a dispute that keeps reopening because it never reads the current status and has no reopen limit. Fix: fetch the live status first and only close from a closeable state, make the close idempotent, count reopens, and after three reopens hand the case to a human with the full timeline. A reopen is usually new information, not a failed close.

Not specified by the original author.

TL;DR

Closing a dispute without uploading evidence forfeits it: networks decide uncontested chargebacks against the merchant by default. Never let the agent close a dispute before the evidence checklist is complete: order details, proof of delivery or service, customer communication, and the refund policy. Build the evidence gate into the dispute flow so closure is impossible without attachments.

agent closed a dispute without uploading evidence: lost the chargeback by default

Use this when

• An agent closed a dispute without evidence and lost by default
• Dispute handling lacks an evidence checklist
• You need an evidence gate before closure

Not for this skill when

• The dispute was lost despite good evidence (issuer decision)
• The dispute is still open and evidence can still be submitted
• You are debugging the dispute webhook rather than the flow

Steps

1. Confirm the loss was by default (no evidence submitted), not on the merits. Expected: The cause is isolated.

2. Assemble the evidence package now in case representment is still possible. Expected: Recovery is attempted where allowed.

3. Define the evidence checklist: order, delivery proof, customer messages, policy. Expected: The requirement is explicit.

4. Gate dispute closure on the checklist: the agent cannot close without attached evidence. Expected: Skipping is structurally impossible.

5. Set deadline alerts well before the network's evidence cutoff. Expected: Evidence is never late.

6. Review lost disputes monthly to improve the evidence templates. Expected: The process learns.

Tool compatibility

Chargeback representment flows (Stripe, Adyen, PayPal); network dispute deadlines.

Variant phrasings

dispute closed no evidence lost chargeback

The incident phrased directly.

chargeback evidence checklist agent

The guardrail phrasing.

lost dispute default no representment

The outcome phrasing.

Why it happens

Card networks run disputes on deadlines and defaults: if the merchant submits nothing by the cutoff, the issuer wins automatically without weighing the facts. An agent optimizing for inbox-zero will close disputes as resolved, not realizing that closure without evidence is surrender. The evidence gate reframes closure as a legal filing with a checklist, not a status update. Given representment windows are short and unextendable, the deadline alert is as important as the checklist itself.

Edge cases / pitfalls

• Evidence requirements differ by dispute reason (fraud vs service-not-rendered); template per reason code.
• Partial evidence is better than none, but complete packages win more often; do not let perfect block timely.
• Some disputes are unwinnable on cost-benefit; define a write-off threshold so the agent does not spend more than the dispute is worth.

Provenance

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

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

Thread query: agent closed a dispute without uploading evidence: lost the chargeback by default

TL;DR: Closing a dispute without uploading evidence forfeits it: networks decide uncontested chargebacks against the merchant by default. Never let the agent close a dispute before the evidence checklist is complete: order details, proof of delivery or service, customer communication, and the refund policy. Build the evidence gate into the dispute flow so closure is impossible without attachments.

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.