How does a webhook signature work?
The provider and the merchant share a secret for each webhook endpoint. When the provider sends a webhook, it calculates a hash-based message authentication code over the payload, often together with a timestamp, and puts the result in a header. The merchant’s server repeats the calculation with its copy of the secret and compares. Stripe’s documentation describes its scheme: a header with a timestamp and a signature, generated with HMAC and SHA-256 over the timestamp and the JSON payload. If the values match and the timestamp is recent, the message came from the provider and was not changed on the way.
Why does it matter?
Webhooks often trigger money movements: marking an order paid, crediting a balance, releasing goods. Stripe notes that without verification an attacker could send fake events to fulfil orders or change records. As an illustrative example: an endpoint that accepts any well-formed POST can be sent a fake success message for an unpaid order. With signature checks, that request fails verification and is rejected before any business logic runs.
What else is needed?
A signature proves the sender, not the outcome. Handlers should still process events idempotently, because the same event can arrive more than once, and should never downgrade a final status. Secrets should be rotated and kept out of code, and a status that matters can be confirmed by calling the provider’s API before acting on it.
Where does Omno use it?
When creating a webhook in Omno’s dashboard, merchants can choose an authorisation method for deliveries. Omno’s webhooks guide also asks merchants to process webhooks idempotently, never overwrite a final status with an earlier one, and confirm with Get Transaction Info when in doubt, rather than trusting redirects or browser events.