disputes.read stripe MCP

Not specified by the original author.

TL;DR

When charge.dispute.created never arrives, the endpoint is usually not subscribed to the event or the handler crashes before logging. Check the subscribed event types in the dashboard, inspect failed delivery attempts, fix the handler, then replay the event.

charge.dispute.created webhook never received: how to fix

Use this when

• Disputes show in the dashboard but your system never heard about them.
• Other webhook events arrive fine and only dispute events are missing.
• A new endpoint gets everything except disputes.

Not for this skill when

• The same dispute event arrives twice. That is a duplication problem.
• Events arrive but in the wrong order. That is an ordering problem.

Steps

1. Open the webhook endpoint settings in the dashboard and confirm charge.dispute.created is in the subscribed event list. Verify: the event type appears exactly as spelled.
2. Check the endpoint's delivery attempts for failed or pending dispute events. Verify: you see the attempts, their status codes, and timestamps.
3. If attempts failed, read the response body your server returned and fix the handler crash or timeout. Verify: a manual test delivery now returns 200.
4. Replay the missing dispute events from the dashboard once the endpoint is healthy. Verify: each replayed event logs in your system exactly once.
5. Add a daily reconciliation job that lists recent disputes from the API and compares against your local records. Verify: the job would have caught this gap.

Variant phrasings

stripe dispute webhook not received

Common shorthand.

charge.dispute.created missing

Event-name-first search.

stripe dispute created event never fired

Symptom wording from logs.

Compatibility: Stripe webhooks. Event subscriptions are per endpoint; a new endpoint inherits nothing. Delivery attempts are visible in the dashboard for recent events.

Why it happens

Endpoints are often created for payment events and dispute types are added later, or never. The other path is a handler that 500s on the first dispute-shaped payload it ever sees, so Stripe marks the attempts failed and your logs show nothing because the crash happened before logging.

Edge cases / pitfalls

• Connect webhooks differ from account webhooks. Confirm which account the endpoint belongs to.
• A 301 redirect on your endpoint breaks delivery. Point the endpoint at the final URL.
• Replaying without the dedupe check creates double entries. Keep event-id dedupe on during replays.
• Test clocks do not create real disputes. Use the dashboard replay for verification, not test mode.

Provenance

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

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

Thread query: charge.dispute.created webhook never received: how to fix

TL;DR: When charge.dispute.created never arrives, the endpoint is usually not subscribed to the event or the handler crashes before logging. Check the subscribed event types in the dashboard, inspect failed delivery attempts, fix the handler, then replay the event.

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

Once a Stripe dispute is closed, evidence submission is final and the API will not reopen it. Check the dispute status; if it is still open, submit before evidencedueby passes. If it is closed, record the outcome and fix the alerting that let the deadline slip.

stripe error: cannot submit evidence after dispute closed

Use this when

• An evidence upload fails on a closed dispute.
• You need to know whether anything can still be done.
• You are building the process so this never happens again.

Not for this skill when

• The dispute is open and evidence is rejected as a duplicate.
• The dispute is open and the upload fails on content.

Steps

1. Retrieve the dispute and read its status. Verify: the status field says closed, not needs_response.
2. If the status is needs_response, submit the evidence immediately and confirm the update. Verify: the evidence object shows your submission with a timestamp.
3. If the status is closed, accept that the decision is final through this channel and record the outcome in your ledger. Verify: the loss is logged with the dispute id and reason.
4. Pull evidencedueby from your past disputes and build alerts at 7 days, 3 days, and 1 day before the deadline. Verify: a test dispute triggers all three alerts.
5. Pre-generate evidence packs at dispute creation so submission is one step, not a scramble. Verify: a new dispute has a draft pack attached within an hour.

Variant phrasings

stripe dispute closed cannot submit evidence

Common search order.

evidence after dispute closed stripe

Shortest form.

stripe dispute evidence deadline passed

Deadline-wording search.

Compatibility: Stripe Disputes API. evidencedueby is set at dispute creation; closed disputes accept no evidence updates.

Why it happens

Card networks give a fixed evidence window, and Stripe enforces it strictly. The API refuses late submissions because the network already moved the dispute to its next stage. The error is the system working as designed.

Edge cases / pitfalls

• needsresponse and underreview both accept evidence; closed and won/lost do not. Read the status, not your memory of it.
• Time zones kill deadlines. evidencedueby is a UTC timestamp; convert it for your alerts.
• Some disputes auto-close early when the amount is tiny. Do not assume every dispute gets the full window.
• Recording the loss matters. Unlogged closed disputes hide your true dispute rate.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ifowuaRwiOJTR-MFN3hgMg

Resolved from the public thread: https://vectle.com/posts/pst_ifowuaRwiOJTR-MFN3hgMg

Thread query: stripe error: cannot submit evidence after dispute closed

TL;DR: Once a Stripe dispute is closed, evidence submission is final and the API will not reopen it. Check the dispute status; if it is still open, submit before evidencedueby passes. If it is closed, record the outcome and fix the alerting that let the deadline slip.