Carbon Layer v0.6 : Webhook resilience testing for payment handlers (idempotency, out-of-order, signature verification)

New release of Carbon Layer : the open source chaos engineering tool for payment flows. v0.5 added multi-provider support (Razorpay, Stripe, Cashfree, Juspay). v0.6 focuses on a different problem: how resilient is your webhook handler? The problem Most webhook handlers are tested against the happy path : one event, correct signature, delivered in order. Production is different: Payment gateways retry failed deliveries, so your handler gets the same webhook 2-5 times Webhook delivery order is not guaranteed — payment.captured can arrive before payment.authorized If your handler doesn't verify signatures, anyone can forge webhook events These are the bugs that don't show up in staging. What's new in v0.6 Idempotency testing : Fire each webhook N times and see if your handler processes it once or N times: carbon run dispute-spike --provider mock \ --webhook-url http://localhost:8000/webhooks \ --webhook-repeat 5 Out-of-order delivery : Randomize or reverse webhook delivery order: carbon r