Webhooks and Event Driven Payments

Polling is the simplest way for a client to learn what happened to a payment. Keep asking the API for the status until it changes. It works, but it is wasteful, because the client makes many calls that return the same answer, and it is slow, because the client only learns about a change at the next poll. Webhooks solve this by reversing the direction. The client registers a URL with the bank, and the bank sends an HTTP POST to that URL whenever a relevant event occurs, such as a payment being accepted, rejected, settled, or returned. The client learns about the change immediately, with a single notification, and the bank does not have to handle thousands of polling requests. For payment status, which is the most common use case, webhooks are now the expected pattern. A webhook integration needs careful design to be reliable. The bank must sign each webhook payload so the client can verify it really came from the bank, and the client must return a success response quickly, so the bank knows the notification was received. If the client's endpoint is down, the bank must retry the delivery with a backoff strategy, and must eventually give up and record the failure, so that operations can investigate. Events must be delivered in order where order matters, and they must be idempotent, so that a duplicate delivery does not cause the client to process the same payment twice. The client also needs a way to catch up on missed events, usually by calling a status API, because no delivery mechanism is perfect. From a BA perspective, webhooks are a product feature that needs clear requirements. Which events are published, what data does each event carry, what is the retry policy, how long are events retained, and how does a client subscribe and unsubscribe? The developer experience matters too, because a corporate developer needs a test environment where they can trigger events on demand and see the payloads. Good webhook documentation includes example payloads for every event type, including the error cases, because a developer who has never seen a rejection event will build the wrong handling for it. Webhooks done well make the whole payment experience feel real time, and done badly they become a source of missed updates and reconciliation breaks. A worked example shows webhooks in action. A corporate customer creates a payment of EUR 25,000 through the bank API and receives a 202 Accepted response with status ACCP. The customer does not poll the status endpoint; instead it waits for a webhook. When the payment is credited to the beneficiary, the bank sends a POST to the customer's registered webhook URL with an event of type payment.credited, the payment identifier, the status ACCC, and a timestamp. The customer's system verifies the signature, records the event, and marks the payment as settled in its own system. The whole flow takes seconds, and the customer does not need to poll. If the customer's endpoint is down when the bank sends the webhook, the bank retries after 1 minute, then 5 minutes, then 15 minutes, until the customer acknowledges or the maximum number of attempts is reached. A failure scenario tests webhook handling. A payment is credited, and the bank sends a payment.credited webhook, but the customer's endpoint returns a 500 error because its database is down. The bank retries, and on the second attempt the customer's endpoint returns a 200, so the webhook is delivered. But the customer's system had already polled the status endpoint and marked the payment as settled, so when the webhook arrives, the customer must recognise it as a duplicate event and ignore it, using the event identifier. If the customer processes the webhook as a new event, it may credit the beneficiary twice in its own system. The defence is the event identifier: the client stores the identifiers it has processed and ignores any webhook whose identifier it has seen before. For a business analyst, the requirement is to define the event types, the retry schedule, the signature scheme, and the duplicate handling, and to test each with a real webhook. Last reviewed 7 November 2026. Further reading: webhook delivery guidance; bank API developer documentation. Take a payment of EUR 10,000 that a merchant is waiting for. The merchant registered a webhook URL with the bank. When the payment is accepted, the bank sends a POST to that URL with an event of type payment.accepted and the payment identifier. When it settles, the bank sends payment.settled. When the merchant's system receives the event, it checks the signature, verifies the event identifier has not been seen before, updates the order status, and returns 200 OK. The whole round trip takes less than a second, and the merchant never polls. If the merchant's endpoint is down, the bank retries after 1 minute, 5 minutes, 15 minutes and 1 hour, and after 24 hours moves the event to a dead letter queue for manual review. Webhook ordering and duplication are the two failure modes that break integrations. Suppose the bank sends payment.settled before payment.accepted, because the two events were processed by different services. The merchant's system sees a settled payment it never saw accepted, and does not know what to do. Or suppose the bank delivers the same event twice, because the first delivery timed out. The merchant's system processes it twice and credits the customer twice. The fixes are an event sequence number, so the client can order events, and an event identifier, so the client can deduplicate. A BA should specify both, plus the retry policy and the dead letter process, because a webhook system without them is unreliable by design. Webhook requirements are a product specification. Which events are published, what data each event carries, what the retry policy is, how long events are retained, and how a client subscribes and unsubscribes. The developer experience matters too: the sandbox must let a developer trigger each event on demand and see the payload, including the error events, because a developer who has never seen a rejection event will build the wrong handling for it. The BA should also define the service level for webhook delivery, such as 95 percent of events delivered within 5 seconds, because a webhook that arrives an hour late is not a real time notification.