agent's adyen HMAC secret rotated: every notification failing validation
Fixes Adyen notification validation failures after an HMAC secret rotation. Use when every notification suddenly fails HMAC validation because the signing secret changed. Not for single-notification failures or signature code bugs.
agent's adyen HMAC secret rotated: every notification failing validation
TL;DR
The HMAC secret used to sign Adyen notifications was rotated, but your validator still uses the old one. Load the new secret into every notification receiver, keep the old one accepted briefly for in-flight messages, and reprocess anything rejected during the gap. All-failing-at-once is the signature of a rotation.
agent's adyen HMAC secret rotated: every notification failing validationSteps
- Confirm the rotation in the Adyen dashboard: check the HMAC key's last-changed timestamp. Success check: the timestamp lines up with when failures started.
- Update the HMAC secret in every service that validates notifications, not just the main one. Success check: each receiver's config matches the new secret.
- Accept both the old and new secret for a short overlap window to cover in-flight notifications. Success check: notifications signed either way validate.
- Reprocess or ask Adyen to resend notifications rejected during the gap. Success check: no business event was lost to the rotation window.
- Document the rotation procedure: who rotates, who updates receivers, and the overlap window length. Success check: the next rotation is a checklist, not an incident.
When this applies
- Every Adyen notification fails HMAC validation at the same time.
- Failures started right after a credential rotation.
- Multiple receivers or environments need the new secret.
When it doesn't
- A single notification failing; that is tampering or a code bug.
- Validation that never worked; check your HMAC implementation first.
- API request signing failures; notifications use a separate secret.
Tool + version compatibility
Adyen notifications and HMAC validation (all current API versions).
"adyen hmac validation failed after rotation"
Update every receiver and allow a brief overlap window.
"adyen notification signature invalid new hmac key"
The dashboard rotation timestamp tells you exactly when it broke.
"adyen all webhooks failing hmac"
All-at-once failure is a rotation until proven otherwise.
Why it happens
Adyen signs each notification with an HMAC key, and your code re-computes the signature with the same key to prove the message is genuine. Rotate the key on Adyen's side without updating your side and every signature check fails, because your code is verifying against a secret Adyen no longer uses. Agent-operated integrations often store the secret in one place but validate in several, so one missed receiver keeps failing after the fix.
Edge cases / pitfalls
- Find every receiver before rotating; the one you forget is the one that pages you at night.
- The overlap window should be minutes to hours, not days; long overlaps weaken the tamper check.
- Log validation failures with the key identifier, never the key; debugging must not leak secrets.
- Test rotation in the test environment first; the procedure is the same and the stakes are zero.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstCo1U2DN7V2nRVQ5TbwJiA