## TL;DR

A live payment link must be verified with the live API key, never the test key: Mollie's keys are environment-scoped, so a test key cannot validate live payment data. Keep separate webhook handlers or a per-environment key lookup, verify the signature with the key that matches the payment's mode, and re-test with a live payment. Log the key mode with each webhook so a mismatch is visible immediately.

```text
mollie webhook rejected: test API key used on a live payment link
```

## Use this when

- Mollie webhook verification fails on a live payment
- You recently promoted code from staging to production
- One codebase serves both test and live Mollie payments

## Not for this skill when

- The webhook never reaches your server (that is a routing or firewall problem)
- The signature fails even with the correct key (check raw body parsing)
- You need to debug the payment itself rather than its verification

## Steps

1. Identify the mode of the failing payment: live payment links always need the live API key for verification.
   Expected: You know whether the payment is test or live.
2. Store test and live API keys separately and select the key based on the payment mode, not a single global key.
   Expected: Webhook verification uses the key whose mode matches the payment.
3. Re-run the webhook delivery (resend it from the Mollie dashboard, or trigger a new live payment) and verify with the live key.
   Expected: Signature verification passes and the webhook is accepted.
4. Add a mode check at the top of the webhook handler that routes payments whose mode does not match the configured key.
   Expected: Future mismatches fail fast with a clear log instead of a cryptic rejection.
5. Audit your deployment: confirm production runs with the live key and staging with the test key, and that no config mixes them.
   Expected: Each environment uses exactly one key mode.

## Tool compatibility

Mollie Payments API webhooks; any server stack that can select credentials per environment. The test/live key split is enforced server-side by Mollie.

## Variant phrasings

### mollie webhook signature invalid on live payments

Often the same root cause: the wrong environment key was used to verify.

### mollie test key on production webhook

The deployment anti-pattern behind this error; separate the keys per environment.

### mollie webhook rejected 401

Rejections on the webhook endpoint frequently trace back to environment key confusion.

## Why it happens

Mollie issues separate test and live API keys, and signatures are computed against the key of the payment's own environment. A live payment's webhook payload can only be verified with the live key. When staging config leaks into production, or one handler serves both environments with a single key, verification of live webhooks fails. The rejection looks like a security error, but it is really an environment mismatch.

## Edge cases / pitfalls

- Mollie webhooks are delivered with a delay and can be retried: verify idempotently so a retried webhook does not double-apply.
- If you rotate keys, update both environments; an old live key fails the same way as a test key.
- Do not fix this by disabling signature verification: that removes the protection against forged webhooks.

## Provenance

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