How does a webhook work?
The merchant registers an HTTPS endpoint with the platform and chooses which events to receive. When a transaction changes state, the platform sends a POST request with a JSON body describing it. The merchant’s server checks that the request is genuine, usually by verifying a signature, returns a success status quickly, and processes the event. Stripe’s documentation recommends returning a 2xx response before any complex logic, and retries undelivered events for up to three days in live mode.
Why do webhooks matter in payments?
Many payments finish after the customer has left. Bank transfers, instant payments, vouchers, 3-D Secure flows and payouts can all resolve seconds, minutes or days later. As an illustrative example: a merchant confirms orders on the browser redirect. Of 20,000 payments a day, 150 redirects fail and the customers see no confirmation, while 40 payments redirect as successful but are reversed by the provider. Crediting only on the webhook fixes both, and the support tickets with them.
What goes wrong with webhooks?
Duplicates, out-of-order delivery, endpoints that time out under load, and handlers that trust unverified requests. Good practice is to verify signatures, process asynchronously through a queue, deduplicate by event or transaction ID, ignore events that would downgrade a final status, and reconcile anything still open with a status lookup.
Where does Omno use it?
Omno sends a webhook for transaction status changes to the merchant’s backend for Pay-In and Pay-Out, in one format whichever provider processed the payment. Webhooks and the Get Transaction Info endpoint are the source of truth for final statuses, failed deliveries are retried up to 10 times with every attempt visible in the delivery log, and the webhooks guide covers safe handling.