If a platform wants to track payments that become disputes, which event should they listen for?

If a platform wants to track payments that become disputes, which event should they listen for?

• A. balance.available
• B. charge.dispute.created
• C. payment_intent.succeeded
• D. charge.refunded

Answer: (B)

Disputes are a separate lifecycle event from payments and refunds, so you want the webhook that fires when a dispute is opened against a charge. The event that signals this is the one that indicates a dispute was created for a charge. Listening to it gives you immediate visibility into which payments become disputed, and the payload links the dispute to the associated charge so you can update your records and begin handling the dispute. Other events like balance.available, payment_intent.succeeded, or charge.refunded don’t indicate a dispute has started, so they wouldn’t reliably track disputes. Once you’re set up, you can also watch for updates and closure of disputes to reflect the full status in your system.

Disputes are a separate lifecycle event from payments and refunds, so you want the webhook that fires when a dispute is opened against a charge. The event that signals this is the one that indicates a dispute was created for a charge. Listening to it gives you immediate visibility into which payments become disputed, and the payload links the dispute to the associated charge so you can update your records and begin handling the dispute. Other events like balance.available, payment_intent.succeeded, or charge.refunded don’t indicate a dispute has started, so they wouldn’t reliably track disputes. Once you’re set up, you can also watch for updates and closure of disputes to reflect the full status in your system.