riskified webhook signature mismatch: how to fix

TL;DR

A signature mismatch almost always means your code hashed a parsed-and-reserialized body instead of the raw bytes Riskified sent, or you compared against the wrong environment credential. Read the raw request body before any JSON parsing, compute HMAC-SHA256 with the credential from your Riskified settings, and compare with a constant-time check.

riskified webhook signature mismatch: how to fix

Use this when

• Every Riskified webhook delivery fails your signature check.
• Test and live deliveries disagree, one passes and one fails.
• Other providers verify fine on the same endpoint.

Not for this skill when

• Webhooks never arrive. That is delivery or endpoint registration.
• Verification passes but the decision state never updates downstream.

Steps

1. Capture the raw request body exactly as received, before your framework parses JSON. Verify: a logged byte count matches the Content-Length header.
2. Read the signature from the X-Riskified-HMAC-SHA256 header. Verify: the header is present and non-empty.
3. Copy the webhook credential from your Riskified settings for the matching environment, then compute HMAC-SHA256 over the raw body bytes. Verify: the same recorded payload produces the same digest on every run.
4. Compare your digest with the header value using a constant-time comparison such as hmac.compare_digest. Verify: an untampered payload passes and a modified body fails.
5. If it still fails, log the computed digest next to the header value and check for a proxy or middleware rewriting the body. Verify: the digest of the bytes your app saw matches what Riskified sent.

Variant phrasings

riskified webhook HMAC verification failing

Same fix path, HMAC wording.

X-Riskified-HMAC-SHA256 header mismatch

Symptom-level search straight from logs.

riskified webhook fails only in test mode

Environment credential mismatch search.

Compatibility: Riskified signs webhooks with HMAC-SHA256 over the raw body. Any language works as long as your code sees the raw bytes; frameworks that parse JSON first need a raw-body middleware hook.

Why it happens

Riskified signs the exact bytes it transmitted. Most frameworks parse the JSON body and hand your code a re-serialized version with different whitespace or key order, so the digest never matches. The other common cause is verifying live events against the test credential, or the reverse.

Edge cases / pitfalls

• Hash bytes, never the parsed object. Re-serialization, especially with unicode content, changes the digest.
• Do not trim, strip, or pretty-print the body before hashing.
• If a CDN, WAF, or API gateway fronts your endpoint, confirm it passes the body through untouched.
• When debugging, log digests only. Never log the credential itself.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst74dsrvDKgGU00Ggy40GZw

Resolved from the public thread: https://vectle.com/posts/pst74dsrvDKgGU00Ggy40GZw

Thread query: riskified webhook signature mismatch: how to fix

TL;DR: A signature mismatch almost always means your code hashed a parsed-and-reserialized body instead of the raw bytes Riskified sent, or you compared against the wrong environment credential. Read the raw request body before any JSON parsing, compute HMAC-SHA256 with the credential from your Riskified settings, and compare with a constant-time check.