A payment succeeds, a booking changes or a delivery is updated in another platform. Your business app needs to learn about that change and take the right action. A webhook is an incoming notification from that external system. It can reduce manual checking, but the notification alone does not make an integration dependable.
For an Irish business connecting orders, customer records and operational tools, the useful planning question is: what should happen if the notification is late, repeated or cannot be processed? This guide turns that question into a practical integration brief. It complements our guide to B2B customer portals.
Start with one business event and its owner
Describe the outcome in business language before choosing a technical approach. For example: when a confirmed order is ready for dispatch, create one packing task for the operations team. Name the system that owns the order status and the person who handles exceptions.
An illustrative workflow might involve a shop, a warehouse app and an accounting platform. Each system can report something different at the same moment. Decide which one is authoritative for stock, fulfilment and payment status. Our inventory and ERP integration guide explores those ownership decisions in more detail.
Verify who sent the notification
An internet-accessible endpoint should not trust a request simply because its JSON looks familiar. Use the sending platform's documented verification mechanism and maintain separate configuration for testing and production. Include a procedure for rotating verification secrets without losing valid deliveries.
Stripe's webhook documentation covers signature verification, repeated events, delivery order and endpoint responses. Its details apply to Stripe; another provider may use different signing and retry rules. Ask the implementation team to link the exact provider documentation in the handover instead of assuming all webhooks behave identically.
Make repeated delivery safe
Define the business action that must happen only once. Recording an incoming event identifier can help, but the design must also protect the actual operation. Two events concerning the same order should not produce two dispatch tasks simply because they have different event identifiers.
Write an acceptance example: receiving the same confirmed-order notification twice leaves one packing task and an understandable processing history. Then test a failure immediately after the task is created but before the integration records completion. This is where a retry can expose a gap between the event log and the business operation.
Separate receipt from successful processing
Keep a durable record of accepted work and a clear distinction between received, processing, completed and failed states. The endpoint's response should follow the provider's requirements. A success response should not hide a notification that vanished before it could be processed.
For a busy service, a queue can help separate incoming notifications from slower downstream work. Define who operates that queue, how failures are surfaced and how long unresolved items may remain. Start with operational requirements; a small integration does not automatically need a complicated distributed architecture.
Plan for late and out-of-order updates
Decide how the integration determines the latest valid state. In some workflows it should fetch the current record from the source system rather than applying every arriving payload as if it were current. Document what happens when that lookup fails or the external service is unavailable.
For example, a delayed cancellation should not silently overwrite a newer, authorised change without checking the workflow rules. State transitions need explicit decisions. Reuse the access-boundary thinking in our SaaS permissions guide when deciding which automated actions can change customer or staff records.
Give support staff a useful exception view
Staff need enough information to identify the affected business record, understand the failure and decide the next action. Show a safe reference, status, last attempt and owner. Avoid exposing full incoming payloads to everyone who can open an admin page.
Agree which fields belong in operational logs and how long they are needed. If a payload can contain customer details, minimise what is copied into alerts. Keep replay controls restricted and record who used them. A clear exception screen often provides more operational value than a large dashboard of successful event counts.
Run a failure rehearsal before launch
Use a small test pack covering a valid notification, an invalid signature, repeated delivery, delayed delivery, a downstream outage and recovery after a processing failure. Confirm the resulting business records as well as the HTTP responses. Include one notification for a record that no longer exists.
Measure whether failures are noticed and whether the responsible person can resolve them with the handover instructions. If processing triggers a receipt or account message, include the checks from our transactional-email guide. A successful integration should produce the intended customer outcome, not just a green request log.
Create a handover that someone can operate
Record the event types, source system, verification method, duplicate-handling rule, processing states, alert owner and replay procedure. Add the test evidence and the steps for disabling an unsafe action while preserving incoming work for review.
Elephantfly's web development services cover business applications and integrations. If you need to connect an existing workflow, contact the team with the systems involved, the event you want to act on and the operational problem it should solve.
