Webhook
Instead of your server asking another system over and over whether something happened, the other system calls you the moment it does, for example when a payment succeeds.
Updated October 2026 · with examples from our own builds
What does webhook mean in practice?
Payment gateways, app stores and many SaaS tools report events by webhook: they call a URL on your server with the details of what just happened, and your system updates its records, sends a receipt or grants access.
Money and access change state here, so receivers need care. The same event can arrive twice, late or never, and anyone who finds the URL can try a fake one. A sound receiver checks the signature, stores each event once, answers quickly and does the work afterwards.
Offering webhooks to your own customers puts you on the other side of that contract: signing what you send, retrying failures on a schedule and switching off endpoints that keep failing.
Webhook at a glance
- Must check
- The signature over the raw request body
- Must handle
- Duplicates, delays and missed deliveries
- Typical senders
- Payment gateways, app stores and billing services
Where has webhook come up in our builds?
Stripe sends payment succeeded, payment failed and charge refunded to one webhook on the mobile backend. The web backend has no webhook on purpose: both write to the same database, so a second consumer could process the same event twice.
Pakka's own webhooks to business customers are signed with HMAC-SHA256 over a timestamp and the body and retried at 1 m, 5 m, 30 m, 2 h, 12 h and 24 h. An endpoint that fails eight times in a row is switched off, and redirects are not followed.
The Razorpay receiver checks the signature over the raw body, drops events that belong to other apps on the shared account, stores each event under a unique ID and answers 200 before doing the work. A replay job sweeps failed events every ten minutes, up to six attempts with doubling back-off.
Common questions about webhook
What if a payment webhook never arrives?
Don't rely on it alone. Keep a way to ask the provider for the payment's status directly, and run a reconciliation or replay job that finds payments your records haven't caught up with.
Why would a payment webhook arrive twice?
Providers retry when they don't get a quick success reply, and networks drop responses. Store each event under its ID before acting on it, so a second delivery is recognised and does nothing.
Related terms
Sources
Planning a product and not sure where webhook fits? Ask us, or browse all 116 terms in the glossary.