We fired 150 dispute webhooks at a payment service. 12 handlers crashed. Here's what we built.

Every company processing payments tests the happy path. Payment succeeds, order gets fulfilled, customer gets a confirmation email. That’s the flow that gets reviewed, tested in staging, and monitored in production. What doesn’t get tested is everything else. Dispute spikes. Refund storms. Gateway errors that leave orders stuck. Webhook sequences your handlers were never built to handle at volume. These are the failure modes that show up in production usually at the worst possible time. The problem is not that engineering teams don’t care. It’s that the tools to test this don’t exist. Why you can’t test this in Razorpay’s sandbox Razorpay’s test API cannot create disputes. Disputes are raised by banks and card networks, not merchants. There is no POST /disputes endpoint. Even if you could trigger disputes manually, you can’t fire 150 of them in 10 seconds on a test account. Razorpay would rate limit you. And you can’t control the timing or sequence of webhook events in any sandbox. So