Несовпадение HMAC только на одном вебхуке (с акцентами в имени)

Готов поспорить, что проблема в круге JSON.parse → JSON.stringify, а не в кодировке, которую вы передаёте в update(). Поэтому её смена ничего и не дала.

HMAC считается от тех самых байтов, которые подписал партнёр. Когда вы парсите и заново сериализуете, вы подписываете свою сериализацию данных, а не их. Для обычных ASCII-payload'ов с компактным форматированием результат часто получается байт в байт одинаковым, так что evt_2051 и evt_1001 проходят по везению. В evt_2044 есть не-ASCII символы, и именно там сериализаторы расходятся. Если партнёр отдаёт Zo\u00eb Ram\u00edrez (с экранированием, как по умолчанию делают некоторые энкодеры в Java/PHP/Python), то JSON.stringify выдаст вам буквально Zoë Ramírez, и дайджест изменится. Бывает и наоборот. Порядок ключей, пробелы и формат чисел тоже могут отличаться, но диакритика лучше всего объясняет ваш симптом.

Решение: хешируйте delivery.raw напрямую, не трогая.

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

JSON.parse вызывайте только после того, как подпись проверена. Если вы сохраняли доставки на диск, убедитесь также, что то, что их писало, не перекодировало и не нормализовало текст. Безопаснее всего хранить сырой Buffer.

Раз уж вы всё равно там копаетесь: сравнивайте дайджесты через crypto.timingSafeEqual, а не через ===. Доки: https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

Надеюсь, поможет. Напишите, починила ли 2044 версия с raw.

const payload = JSON.stringify(body);

Проблема в этой строке. Партнёр подписал свои байты, а не то, что получается у вашего JSON.stringify. По моему опыту, "the JSON payload" в таких доках всегда значит сырое тело. Хешируйте delivery.raw как есть, а парсите после проверки.

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

Да, всё так. Буду хешировать delivery.raw, а парсить после. (Мои shell-скрипты для остальных хуков уже так и работают.)

Насчёт везения я бы поспорил: в доках партнёра сказано, что они экранируют не-ASCII, так что 2044 в любом случае должен был упасть.

У меня было то же самое со Stripe-подобным вебхуком, и хеширование сырого тела всё починило. Доки: https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

Согласен насчёт хеширования сырого тела, но я бы немного поспорил с "the JSON payload всегда значит сырое". В доках так говорят вскользь постоянно, наверное, поэтому tess.p на этом и споткнулся, нет?

Одно замечание для реплей-чекера: если сохранённые доставки читали как utf8-строку и писали обратно, BOM или смена CRLF сломают дайджест точно так же. Я бы держал raw как Buffer от начала до конца. А если это когда-нибудь окажется за Express, то express.json() к моменту, когда вы увидите тело, его уже распарсит. Есть два способа обойти это:

// 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
});

Я склоняюсь к B, потому что так сложнее случайно захешировать не то, но A менее инвазивен для существующего приложения. Не уверен, какой из них я бы защищал на ревью.

Везение относилось к успешным проверкам, а не к падению. Экранирование объясняет 2044, но 2051 совпал только потому, что их пробелы и порядок ключей случайно совпали с JSON.stringify, и ничто этого не гарантировало.