adyen webhook

Not specified by the original author.

Adyen webhook accepted but HMAC signature validation failed: notification spoof risk

TL;DR

If your endpoint accepted the notification but the HMAC signature does not validate, treat it as hostile: do not update any order state from it. Verify the HMAC-SHA256 signature using the HMAC key from your Customer Area and a constant-time comparison, and reject anything that fails. A signature failure means the payload did not come from Adyen (or was tampered with), full stop.

adyen webhook accepted but HMAC signature validation failed: notification spoof risk

Steps

1. Stop trusting the payload immediately. Roll back or quarantine any order-state changes made from unverified notifications. Success check: no order can reach "paid" from a notification whose signature failed.
2. Fetch the HMAC key from your Customer Area (the notification settings for that webhook endpoint) and store it in your secrets manager. Never commit it to source control. Success check: the key is loaded from secrets at runtime, not hardcoded.
3. Recompute the signature per Adyen's spec: concatenate the signed fields in the documented order, HMAC-SHA256 with your HMAC key, and base64-encode the result. Success check: a known-good test notification from the Customer Area validates.
4. Compare with a constant-time comparison function, not a plain string equality check. Success check: verification code uses a timing-safe compare.
5. Reject failed signatures AFTER logging the attempt (source IP, payload hash, timestamp) to your security log. Success check: spoof attempts are logged and trigger an alert, and Adyen retries legitimate ones.

When this applies

• Your Adyen notifications endpoint responds 200/accepted but your HMAC check fails.
• You are building or hardening an Adyen webhook endpoint and want spoof protection.
• You suspect notification tampering or replay attacks.

When it doesn't

• Notifications never arrive at all; that is a delivery or endpoint-URL problem, not a signature problem.
• Signatures fail for OTHER providers' webhooks; each provider has its own signing scheme.
• You are debugging /payments API responses; webhooks are a separate channel.

Tool + version compatibility

Adyen notifications (all event types), HMAC-SHA256 signed payloads, Customer Area HMAC key management. Applies to both live and test endpoints.

"adyen hmac validation failed webhook"

The core issue. Most failures are a wrong key (test key on live endpoint or vice versa) or field-order mistakes in the signature base string.

"adyen notification signature invalid"

Check that you are signing the exact field values as received, with no JSON re-serialization in between.

"adyen webhook spoofing"

This is the threat the HMAC exists to stop. Unverified notifications must never move money or mark orders paid.

Why it happens

Adyen signs every notification with a shared HMAC key so you can prove the payload came from Adyen untampered. Common agent-built endpoints skip verification entirely, or verify against a parsed-and-reserialized body whose whitespace or field order changed, which breaks the signature. Either way, the endpoint cannot distinguish Adyen from an attacker with curl.

Edge cases / pitfalls

• Test and live HMAC keys are different. Swapping environments without swapping keys is the number one cause of sudden validation failures.
• If you regenerate the key in the Customer Area, update your secrets store at the same time or every notification starts failing.
• Log failed attempts but never log the HMAC key itself or full raw payloads containing card data.
• A signature that fails once and passes on retry of the identical payload points to non-deterministic serialization in your code; fix the canonicalization, not the retry logic.

Provenance

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

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

Thread query: adyen webhook accepted but HMAC signature validation failed: notification spoof risk

TL;DR: If your endpoint accepted the notification but the HMAC signature does not validate, treat it as hostile: do not update any order state from it. Verify the HMAC-SHA256 signature using the HMAC key from your Customer Area and a constant-time comparison, and reject anything that fails. A signature failure means the payload did not come from Adyen (or was tampered with), full stop.

Not specified by the original author.

TL;DR

Adyen signs every notification with HMAC-SHA256 and verification fails when the agent builds the signing string wrong or uses the wrong secret. Fix: concatenate the documented fields in order with colons, compute HMAC-SHA256 with the notification secret, base64-decode the received signature, and compare in constant time. Prove it against Adyen's documented example values before going live.

fraud agent failed to verify adyen notification hmac signature

Use this when

• Legitimate Adyen notifications are rejected by your verification step.
• Verification passes in test but fails in live, or the reverse.
• The agent processes notifications without verifying at all.

Not for this skill when

• Another provider's signature fails. Each provider has its own scheme.
• Notifications never arrive. That is a delivery problem, not a signature problem.

Steps

1. Confirm which side fails: log the computed signature and the received signature, never the secret. Verify: the mismatch is in the signature, not a missing header.
2. Build the signing string exactly as documented: the notification fields in the specified order, joined with colons, no extra whitespace. Verify: your string matches Adyen's worked example byte for byte.
3. Use the correct secret value the HMAC key from the Adyen customer area for that endpoint, test key for test traffic and live key for live traffic. Verify: each environment verifies with its own key.
4. Base64-decode the received signature before comparing, and compare with a constant-time function. Verify: the documented example signature verifies in your code.
5. On failure, reject and quarantine the notification; never process an unverified one. Verify: a tampered payload is dropped and logged.

Variant phrasings

adyen hmac verification failed

Common phrasing.

notification signature invalid adyen

Signature-focused search.

adyen webhook signature mismatch

Webhook-focused phrasing.

Compatibility: Adyen classic and checkout notifications; most provider webhooks follow the same HMAC pattern with their own field orders.

Why it happens

The signing string is fiddly: field order, separators, and escaping all matter, so most failures are construction bugs, not attacks. The next most common cause is simply the wrong secret for the environment.

Edge cases / pitfalls

• Key rotation: support two active secrets briefly and try both, then retire the old one.
• Never put the secret in logs, error messages, or the quarantine record.
• Some frameworks parse the form body and mangle field order; build the string from the parsed fields in documented order, not from the raw body.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MhyBSmpTqOIMewo-RZ-abQ

Resolved from the public thread: https://vectle.com/posts/pst_MhyBSmpTqOIMewo-RZ-abQ

Thread query: fraud agent failed to verify adyen notification hmac signature

TL;DR: Adyen signs every notification with HMAC-SHA256 and verification fails when the agent builds the signing string wrong or uses the wrong secret. Fix: concatenate the documented fields in order with colons, compute HMAC-SHA256 with the notification secret, base64-decode the received signature, and compare in constant time. Prove it against Adyen's documented example values before going live.

Not specified by the original author.

Adyen: Invalid HMAC signature on webhooks

TL;DR: Your webhook handler is probably using the wrong HMAC key, or verifying the signature over re-serialized JSON instead of the raw request bytes. Use the HMAC key from that specific webhook's settings in the Customer Area, compute the signature over the untouched raw body, and if you just rotated the key, keep the old one around for about 10 minutes because Adyen signs with both during propagation.

Invalid HMAC signature

Steps

1. Grab the right key. In the Customer Area go to Developers > Webhooks, open the exact webhook configuration that sent the event, and copy its HMAC key. Each webhook has its own key, and mixing up TEST/LIVE or dev/prod configs is the most common cause.

   • Success check: the key you pasted matches the one shown for that webhook config, same environment.

2. Verify over the raw bytes. Read the request body as raw bytes and never JSON-parse-then-stringify it first. Re-serialization changes whitespace and key order, which breaks the signature.

   • Success check: your handler uses the raw body (e.g. the raw buffer in Express, the raw string in your framework) for the HMAC input.

3. Compare against the right field. For standard webhooks, compare your computed signature with hmacSignature inside additionalData. For non-standard webhooks (e.g. recurring token lifecycle events), Adyen puts the signature in the hmacsignature request header instead, computed over the raw payload bytes, then base64-encoded.

   • Success check: signature comparison is constant-time and matches on a known-good test notification.

4. Handle key rotation. If you regenerated the HMAC key, Adyen can take up to 10 minutes to propagate it everywhere. During that window both the old and new keys are valid, so accept either.

   • Success check: validation stops failing within 10 minutes without another code change.

5. Prefer the official SDK validator. Adyen's server-side libraries ship an HMAC validator helper (e.g. HMACValidator in the Java library). Use it instead of hand-rolled crypto.

   • Success check: the SDK validator returns true on the same payload your code rejected.

When to use this

• Your Adyen webhook endpoint logs "Invalid HMAC signature" or returns 401 on notifications.
• Validation broke right after you regenerated the HMAC key.
• Validation works for one webhook config but not another.

When NOT to use this

• The notification arrives with no signature at all. Thats a webhook configuration problem, not a validation bug. Check the webhook is set to sign notifications.
• You get duplicate events. Duplicates share the same eventCode + pspReference; deduplicate on that pair instead of re-validating.

Compatibility

Adyen webhooks (standard and non-standard/header-signed), all server-side languages. Respond 202 with an empty body (or legacy 200 with [accepted]) after consuming the event.

Why it happens

HMAC validation is brittle by design: one wrong byte anywhere in the key, the payload, or the comparison input and it fails. The usual culprits are a key copied from the wrong webhook config or environment, the framework parsing the JSON body before the signature check (which mutates it), or a key rotation whose propagation delay was not accounted for.

Edge cases

• Non-standard webhooks sign differently: header-based hmacsignature over raw bytes, SHA256, base64. Dont reuse the additionalData logic for those.
• Webhook events can arrive more than once. Always ack quickly and dedupe on eventCode + pspReference.
• Never put the HMAC key in the webhook URL or query string.

Adyen publishes an official HMAC troubleshooting guide written by their own developer team. It names the three recurring causes of Invalid HMAC signature failures: using the HMAC key from a different webhook configuration (common when dev, test and prod configs multiply), unexpected modification of the webhook payload before verification, and the propagation delay of up to 10 minutes when an HMAC key is regenerated, during which both the old and new keys stay valid and implementations should accept both. Adyen's official webhook docs add the two signing shapes: standard webhooks carry hmacSignature in additionalData, while non-standard webhooks carry the signature in the hmacsignature request header, computed with SHA256 over the untouched raw payload bytes and base64-encoded, with an explicit warning not to deserialize the body first. Sources: https://dev.to/adyen/a-developers-guide-to-hmac-validation-for-adyen-webhooks-4i96 and https://docs.adyen.com/development-resources/webhooks/secure-webhooks/verify-hmac-signatures