Webhook Development and Integration UK

Why webhooks fail quietly

A webhook is just an HTTP POST from one system to another when something happens: a payment succeeded, an order was paid, a contact changed. Simple in principle, but most problems come from treating it as simple. The endpoint does all the work inline and times out. The provider retries and the order is created twice. The server is down for ten minutes and events are lost. Nobody checks the signature, so the endpoint will happily accept a fake payment notification.

We build webhook handling as a small, deliberate piece of infrastructure, not an afterthought in a controller. It's the backbone of most integrations we do, from Stripe and Shopify to CRMs and accounting systems.

Receiving webhooks properly

1. Verify first. Read the raw body and check the signature header using the shared secret: Stripe-Signature, X-Shopify-Hmac-Sha256, X-HubSpot-Signature-v3 or whatever the provider uses. Compare in constant time. Reject anything that fails.
2. Check freshness. Where the signature includes a timestamp, reject old messages to stop replay attacks. Stripe's official libraries default to a 300-second tolerance, and the Standard Webhooks specification recommends the same.
3. Store and acknowledge. Write the event to a table and a queue, then return 2xx immediately. Providers expect a quick response and will retry or eventually disable slow endpoints.
4. Process idempotently. A worker processes the event, using the event ID and unique database constraints so a duplicate delivery changes nothing.
5. Handle order. Events can arrive out of sequence, so where order matters we fetch the current state from the provider's API rather than trusting the payload blindly.

When things go wrong

Failures are normal: an API you call during processing is down, a record is locked, data is invalid. Temporary failures are retried with exponential backoff. Permanent failures go to a dead-letter list on a dashboard showing the payload, the error and a replay button. Alerts go to a named person by email or Teams.

Providers also fail. Most retry for a limited time and then give up. So for anything that matters, such as payments and orders, we add a reconciliation job that periodically asks the provider's API for recent changes and fills any gaps. Webhooks give you speed; reconciliation gives you certainty.

Sending webhooks from your own software

If you run a SaaS product or a platform that partners integrate with, offering webhooks saves them from polling your API. We build the sending side too:

• Subscription management so customers can register endpoints and choose event types.
• Signed payloads following the open Standard Webhooks specification: webhook-id, webhook-timestamp and webhook-signature headers with HMAC-SHA256, so consumers can use existing libraries.
• Retries with backoff, automatic disabling of dead endpoints, and a delivery log customers can see.
• Secret rotation without downtime, and documentation with sample verification code.

This usually sits alongside a public API: see API development and SaaS development.

Testing webhooks before they hit production

Webhooks are hard to test because the events come from someone else's system. We make them testable:

• Provider tools: the Stripe CLI can forward live test-mode events to a local endpoint with stripe listen, and the Shopify CLI can trigger sample webhook topics against a development app.
• Recorded payloads: real (anonymised) payloads are saved as fixtures, so automated tests run the full verify, queue and process path on every code change.
• Duplicate and out-of-order tests: tests deliberately send the same event twice and send events in the wrong order, to prove idempotency and ordering logic.
• Separate secrets per environment: development, staging and production each have their own endpoint and signing secret, so a test event can never touch live data.

Stack and hosting

We typically build receivers in PHP 8 with Laravel queues or Node.js with TypeScript, using Redis or a database-backed queue, and MySQL or PostgreSQL for the event store. Endpoints sit behind HTTPS with rate limiting and are monitored for uptime, and the event log is pruned on a schedule so it doesn't keep personal data longer than needed. Hosting can be on your infrastructure or ours via dijitul hosting. Every project is a fixed-price quote after a free chat: get in touch.

What we deliver

• Webhook receiver endpoints with signature and timestamp verification
• Queue-based processing with retries and dead-letter handling
• Idempotency using event IDs and unique constraints
• Event log and dashboard with replay for failed events
• Reconciliation jobs that compare against the provider's API
• Outgoing webhook system for your own platform: subscriptions, signing, retries
• Developer documentation for your webhook consumers

How it works and what it costs

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.

1. Free chat

   Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.

2. Scoping

   We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.

3. Fixed-price quote

   You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.

4. Build and test

   We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.

5. Hand over and look after

   You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.

Related