With a Webhook, the Server Sends the Request to the Client

In every lesson so far, the client has started the request. A webhook reverses that direction. The server sends a POST to a URL the client registered in advance, to announce that some event happened. The client didn't ask for that request.

This turns the client's endpoint into a server that accepts requests from the internet. So the client must verify that the webhook came from the sender it expects. The verification method is a signature check using a shared secret. The sender computes a signature from the payload and includes it with the webhook. The client redoes that same computation and checks whether it matches the signature it received. This is the same technique used to verify a JWT signature, applied to the webhook's body instead of a token.

If the client's endpoint is unreachable or returns an error, the sender usually resends with growing delays. This is the same pattern as retrying a failed request, because the sender has no other way to know the notification arrived.

GOAL

Explain how a webhook reverses the usual request direction, and how signature verification and resending each address a risk that direction introduces.

A webhook payload arrives claiming an order was paid, but its signature doesn't match what the client computes over the same payload with the shared secret. What should the client do?