What is a webhook, and why do payments need them?
It is how your system learns that something happened. Get it wrong and you ship goods for free.
Waiting on hold to ask whether your parcel arrived is one way to find out. Having the courier ring the doorbell is a much better one. But doorbells ring twice, ring while you are out, and occasionally ring for the wrong house entirely. Build for a doorbell, not for a promise.
One asks five times and gets nothing four times. The other is told once, and occasionally told twice, which is why you build for twice.
Why payments cannot work without them
A payment is not instantaneous from your system's point of view. The customer is redirected away for authentication, or the payment method settles asynchronously, or a dispute arrives three weeks later.
You cannot sit and wait, and you cannot rely on the customer returning to your page, because browsers close, connections drop, and people wander off mid-purchase.
So the provider sends a message to your server when the outcome is known. That message is the webhook, and it is the authoritative record of what happened.
The rule that prevents disasters
Never treat the customer's browser as the source of truth. A customer landing on your success page does not mean the payment succeeded. A customer never landing there does not mean it failed.
Fulfil orders on the webhook, not on the redirect. This single principle prevents the two most expensive mistakes in payment integration: shipping goods for payments that failed, and failing to ship for payments that succeeded while the customer's connection dropped.
The three things that go wrong
Duplicates. Providers retry webhooks when they do not receive confirmation, so the same event can arrive several times. Your handler must be idempotent, meaning processing the same event twice has the same effect as processing it once. Otherwise you refund twice or ship twice.
Out of order arrival. A refund notification can arrive before the payment notification it relates to. Handle state by checking the current truth, not by assuming sequence.
Silent failure. If your endpoint is down, events queue and then arrive in a flood, or expire entirely. Always reconcile against the provider's records rather than trusting that you received everything.
Where you meet it
Behind every order confirmation email, every subscription renewal, every "your refund has been processed" message. If you build anything taking payments, in the most important handler you will write.