Why webhooks
Many payment outcomes settle asynchronously. Instead of polling, the processor sends a webhook: an HTTP callback telling you a charge succeeded, failed, or was disputed.
Receiving safely
- Verify the signature on every webhook so an attacker cannot forge events.
- Treat delivery as at least once, so handle each event idempotently keyed by its event id.
- Respond fast with a success status, then process the work out of band.
Reliability concerns
- The processor will retry if you do not acknowledge, so slow handlers cause duplicates.
- Events can arrive out of order, so reconcile against the payment state machine rather than trusting arrival order.
- Keep a backup reconciliation path in case a webhook is lost entirely.
Key idea
A payment webhook delivers asynchronous status events that you must verify, dedupe by event id, and acknowledge quickly, while reconciliation backs up any lost or out of order delivery.