HMAC mismatch on one webhook only (the one with accents in the name)

I'd bet the problem is the JSON.parse → JSON.stringify round trip, not the encoding passed to update(). That's why changing it did nothing.

HMAC is over the exact bytes the partner signed. Once you parse and re-stringify, you're signing your serialization of the data, not theirs. For plain ASCII payloads with compact formatting, the two often come out byte-identical, so evt_2051 and evt_1001 pass by luck. evt_2044 has non-ASCII characters, and that's where serializers diverge. If the partner emits Zo\u00eb Ram\u00edrez (escaped, as some Java/PHP/Python encoders do by default), JSON.stringify will give you the literal Zoë Ramírez instead, and the digest changes. It can go the other way too. Key order, whitespace and number formatting can also differ, but the accents fit your symptom best.

Fix: hash delivery.raw directly, untouched.

const expected = crypto
  .createHmac("sha256", secret)
  .update(delivery.raw)   // string or Buffer, exactly as received
  .digest("hex");

Only call JSON.parse after the signature checks out. If you saved the deliveries to disk, also make sure whatever wrote them didn't re-encode or normalize the text. Storing the raw Buffer is safest.

While you're in there, compare digests with crypto.timingSafeEqual rather than ===. Docs: https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

Hope that helps — and let us know if the raw version fixes 2044.

const payload = JSON.stringify(body);

This line is your problem. The partner signed their own bytes, not what your JSON.stringify makes. For me, "the JSON payload" in these docs always means the raw body. Hash delivery.raw as it is, and parse after the check.

https://nodejs.org/api/crypto.html

Yep, that's it. I'll hash delivery.raw and parse after. (My shell scripts for the other hooks already work that way.)

I'd disagree on luck: the partner docs say they escape non-ASCII, so 2044 was always going to fail.

Had the same thing with a Stripe-style webhook, and hashing the raw body fixed it. Docs: https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

Agreed on hashing the raw body, though I'd push back a bit on "the JSON payload always means raw". Docs say that loosely all the time, which is probably why this bit tess.p in the first place, right?

One caveat for the replay checker: if the saved deliveries were read as a utf8 string and written back, a BOM or CRLF change would break the digest in the same way. I'd keep raw as a Buffer end to end. And if this ever sits behind Express, express.json() has already parsed the body by the time you see it. Two ways round that:

// option A: keep the bytes next to the parsed body
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf; },
}));

// option B: raw only on the webhook route, parse after verifying
app.post("/hooks/billing", express.raw({ type: "application/json" }), (req, res) => {
  // req.body is a Buffer here
});

I lean towards B because it's harder to hash the wrong thing by accident, but A is less invasive on an existing app. Not sure which I'd defend in review.

The luck was about the passes, not the failure. Escaping explains 2044, but 2051 only matched because their whitespace and key order happened to match JSON.stringify – nothing guaranteed that.