Payments glossary
Webhook
A webhook is an automated HTTP callback a payment provider sends to a merchant's server when an event happens - a payment succeeds, a refund completes, a chargeback arrives - so the merchant's systems can react immediately instead of repeatedly polling an API.
Why payments run on webhooks
Payment outcomes are asynchronous. A customer can pay and then close the browser before returning to the merchant's site; a bank payment can confirm seconds or minutes after checkout; a chargeback lands weeks after the sale. Relying on the customer's redirect back to your site means missing events - the webhook is the channel the provider controls end to end, which is why it, not the redirect, should be the source of truth for order state. The pattern is simple: the merchant registers an HTTPS endpoint, and the provider POSTs a signed event to it whenever something the merchant cares about happens.
Building a webhook handler that does not lose money
Four habits separate robust integrations from fragile ones. Verify signatures - anyone on the internet can POST to a public URL, so authenticate every event before trusting it. Respond quickly with a success status and do the heavy processing afterwards, because slow handlers get timed out and retried. Make handling idempotent - retries mean the same event can arrive twice, and a duplicate must not ship a second parcel. Expect events out of order, and reconcile against the API as a periodic backstop. All of this can be rehearsed in a sandbox before a cent of real money moves.
Last updated:
Payments without the jargon.
One integration, every way Africa pays - we'll handle the acronyms.