Webhook Signature Verification for Stripe and Polar

What a signature proves

Every provider here signs a webhook the same basic way: an HMAC-SHA256 over the request, keyed with a secret only you and the provider hold. Your server computes the same HMAC and compares the two in constant time. A match proves the request came from someone with the secret and that the signed bytes did not change on the way. It proves nothing about when it was sent unless a timestamp is part of what was signed.

The providers differ in the details, and each detail breaks a hand-written check: the header name, what gets signed besides the body, how the secret becomes a key, and whether the digest is hex or base64. The table further down lists all of them.

Verify the raw body, not the parsed one

The signature covers bytes. Parse the JSON and write it out again and the bytes change, even when the data does not: whitespace, key order and escaping all move. Read the body as a string, verify that string, and only then parse it.

In Nuxt, that is readRawBody from h3:

export default defineEventHandler(async (event) => {
  const body = await readRawBody(event, 'utf8')
  const signature = getHeader(event, 'stripe-signature')
})

When a check fails, the tool tries the usual changes on the body you pasted: trimmed, LF and CRLF line endings swapped, a byte order mark removed, and the JSON written compact or indented. If one of them matches, the body changed after the provider signed it, and the tool says which change it was.

Polar's two keys

Polar sends Standard Webhooks headers, but the key depends on when the secret was made. Secrets from 8 September 2026, 00:00 UTC onward are Standard Webhooks secrets: the part after whsec_ is base64, and its decoded bytes are the key. Older secrets use Polar HMAC, where the key is the whole whsec_… string as UTF-8.

Polar's SDKs from 1.0.0-alpha.19 try both keys. A plain Standard Webhooks library tries only the new one, so for an older secret, base64-encode the whole string and pass that instead. The verifier tries both and names the one that matched.

Timestamps, replays and duplicates

Stripe, Polar, Standard Webhooks and Paddle sign a timestamp, and a server should refuse a delivery whose timestamp sits too far from its own clock, even when the signature matches. That stops an attacker who captured one request from replaying it later. Keep the server's clock synced. Stripe signs each retry afresh, with a new timestamp.

Lemon Squeezy, Creem and GitHub sign the body alone, so a captured request verifies forever. Retries also mean the same event can arrive twice, as Stripe and Creem both warn. Record the event ID once you have handled it, and skip IDs you have seen.

Rotating a secret

Stripe lets you keep an old secret alive for up to 24 hours after rolling it, and sends one v1 signature per active secret in the meantime. Standard Webhooks puts several space-separated signatures in webhook-signature, and Paddle says a header can carry more than one h1 while a secret is rotated out. A check passes when any one of them matches, which is why the tool lists every signature it received and marks the one that did.