webhook idempotency
4 Jul 2026
7 MIN READ

Your Webhook Isn't Reliable Until You Stop Trusting the Gateway

Most backend engineers treat a webhook as a single, trustworthy event. It isn't. Gateways retry on timeout, on 5xx, on their own internal hiccups — and they will send the same event twice, sometimes minutes apart, sometimes days apart. This post walks through why relying on the gateway's event ID alone is not enough, and why idempotency has to be owned and enforced by your own backend, not borrowed from someone else's infrastructure.

Mentioned Technologies

#webhook idempotency#payment gateways#razorpay#backend architecture#distributed systems#api design#nodejs#database design#fintech engineering#system reliability

Frequently Asked Questions

Gateways retry webhooks on timeouts, 5xx responses, or internal hiccups, so the same event can arrive multiple times, sometimes minutes or days apart.

Idempotency means processing the same webhook event more than once has no additional effect, preventing problems like double-charging or double-fulfilling orders.

Store a unique event or idempotency key on your side and check it before acting, so duplicate deliveries are safely ignored rather than reprocessed.

Built this in production

Digital Bank & Secure Payment Platform

FinTech / Digital Banking System — read the case study

Related Reading

Need this built right?

I'm a freelance NestJS & Node.js backend developer. Let's ship your MVP or SaaS.

Hire Me

Ready for more?

Explore other insights in the gallery.

Browse All Posts