Stripe charge.dispute.created webhook: dispute automation playbook

Not specified by the original author.

TL;DR

Treat charge.dispute.created as the start of a timed workflow: classify the dispute reason, pull the order evidence automatically, decide fight or accept by amount and win probability, and submit evidence before evidencedueby. Automate the intake and evidence assembly; keep the fight-or-accept call rule-based with human override for large amounts.

Steps

1. Subscribe to charge.dispute.created and store the dispute id, amount, reason, and evidencedueby. Expected: Every dispute enters your system with its deadline.

2. Auto-pull evidence: order record, delivery tracking, customer messages, and the descriptor shown at purchase. Expected: The evidence pack assembles itself.

3. Apply fight-or-accept rules: fight above a value threshold with strong evidence, accept small or weak-evidence disputes. Expected: Decisions are consistent, not emotional.

4. For fights, submit evidence via the API at least 48 hours before the deadline. Expected: No deadline misses.

5. Track win rate by reason code and feed it back into prevention (descriptors, Radar rules). Expected: Disputes get rarer over time.

When to use

• You want disputes handled without manual monitoring
• Dispute volume justifies automation
• Evidence deadlines are being missed

When not to use

• You have a handful of disputes a year (manual dashboard flow is fine)
• You want to stop disputes happening (prevention playbook instead)
• Amounts are tiny (accepting is cheaper than the evidence labor)

Compatibility

Stripe webhooks charge.dispute.created and charge.dispute.closed; Disputes API. All SDKs.

Variant phrasings

### automate Stripe dispute response

### charge.dispute.created handler

### dispute triage automation Stripe

Root cause

Disputes are time-boxed adversarial processes: the network sets a deadline, the issuer decides fast, and manual inbox-driven handling misses deadlines or submits thin evidence. Automation wins by starting the clock instantly and assembling evidence while humans decide only the judgment calls.

Edge cases

• Test webhooks with dispute fixtures; never test with real chargebacks
• Amounts under the dispute fee may not be worth fighting even with perfect evidence
• Some reasons (duplicate processing with proof) are near-automatic wins: prioritize them

Provenance

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

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

Thread query: Stripe "charge.dispute.created" webhook: dispute automation playbook

TL;DR: Treat charge.dispute.created as the start of a timed workflow: classify the dispute reason, pull the order evidence automatically, decide fight or accept by amount and win probability, and submit evidence before evidencedueby. Automate the intake and evidence assembly; keep the fight-or-accept call rule-based with human override for large amounts.

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

Stripe auto-closes a dispute once evidencedueby passes, and a closed dispute accepts no more evidence. Confirm the status, record the loss with its cause, then build due-date reminders with a buffer so the next deadline never slips. The deadline was always on the dispute object; the miss is a process failure, not a Stripe failure.

stripe error: evidence deadline missed after dispute auto-closed

Use this when

• The deadline passed and the dispute is now closed.
• You need the post-mortem and the process fix.
• Deadlines keep slipping across the team.

Not for this skill when

• The dispute is still open. Submit the evidence now.
• Evidence was rejected on a closed dispute for duplication.

Steps

1. Retrieve the dispute and confirm the status is closed and the reason it closed. Verify: you see the closed status and the original evidencedueby.
2. Record the loss in your ledger with the dispute id, amount, and reason. Verify: the loss is visible in your dispute reporting.
3. Build alerts on evidencedueby at 7 days, 3 days, and 1 day out, converted to your team's time zone. Verify: a test dispute fires all three alerts.
4. Pre-generate a draft evidence pack at dispute creation so submission is one step. Verify: a new dispute has a draft pack within an hour of creation.
5. Assign one owner per open dispute and review the open list weekly. Verify: every open dispute has a named owner and a due date.

Variant phrasings

stripe dispute auto-closed missed deadline

Common search order.

evidencedueby passed dispute closed

Field-first wording.

stripe dispute deadline missed what now

Question-form search.

Compatibility: Stripe Disputes API. evidencedueby is final; auto-close happens server-side with no grace period.

Why it happens

The network's evidence window is fixed and Stripe enforces it mechanically. Miss the timestamp and the dispute moves on without you. It is rarely a surprise in hindsight: the deadline was on the dispute object the whole time, and nobody was watching it.

Edge cases / pitfalls

• Auto-close can happen before the stated deadline for tiny amounts. Do not treat the deadline as guaranteed time.
• Weekends and holidays do not extend the window. The timestamp is the timestamp.
• One owner per dispute beats a shared inbox. Shared inboxes are where deadlines go to die.
• Track deadline misses as a metric. What gets measured gets a process.

Provenance

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

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

Thread query: stripe error: evidence deadline missed after dispute auto-closed

TL;DR: Stripe auto-closes a dispute once evidencedueby passes, and a closed dispute accepts no more evidence. Confirm the status, record the loss with its cause, then build due-date reminders with a buffer so the next deadline never slips. The deadline was always on the dispute object; the miss is a process failure, not a Stripe failure.