A payment webhook is an automated message a payment system sends to another application when a transaction event occurs. It can notify the receiving system about authorization, processing, failure, settlement, return or other status changes.
How does a payment webhook work?
The provider sends an HTTP request to a registered endpoint with an event type and transaction data. The receiving application validates the request, records the event and returns an acknowledgement.
Why not rely on the browser response?
A user can close a page, lose connectivity or manipulate client-side behavior. Server-to-server events provide a more reliable source for updating orders, although they still require reconciliation with the provider's authoritative records.
Which controls are required?
- Verify signatures or message authentication
- Use HTTPS and protected endpoints
- Reject stale or invalid payloads
- Store event IDs and enforce idempotency
- Process events asynchronously when appropriate
- Restrict sensitive logging
How should duplicate and out-of-order events be handled?
Webhook delivery is commonly retried, and events may arrive more than once or in a different order. Use stable event identifiers and transaction state rules rather than assuming every message is new.
Does a webhook prove settlement?
Only an event explicitly tied to final settlement, supported by the provider's records, should update a transaction as settled. A “payment created” or “processing” event does not prove receipt.
