Last updated: 25 June 2026 | Change log
To ensure the webhook body has not been tampered with, you should request an Event-Signature header to be sent with your event.
This contains a Hash-based Message Authentication Code (HMAC) generated from a shared secret and the webhook body itself.
Contact your Implementation Manager to enable the Event-Signature header and receive the signature key. The signature key is unique per merchant and we share it on a secure channel.
Extract the Event-Signature HTTP(S) header from the incoming events webhook request.
- can contain multiple signatures (comma separated)
- the order of the signatures can change, so always use the
keyId
Event-Signature:1/SHA256/XXXXXXXXXXEvent-Signature:{keyId}/{hashFunction}/{signature}| Parameter | Description |
|---|---|
keyId | Numeric reference for the shared secret used to sign the message. The keyId value changes/increments if a new signature is generated. |
hashFunction | The cryptographic hash function used to create the HMAC. Currently supported: |
signature | Hash-based Message Authentication Code (HMAC) hex output. Generated from the webhook body and shared secret using the hashFunction. |
Take the webhook body and shared secret, then use the hashFunction to generate the HMAC signature.
Compare your generated HMAC signature from Step 2 with the signature received in the Event-Signature header.
| Signature outcome | Follow on action |
|---|---|
| Signatures match | Respond with a 200 HTTP(S) status code. |
| Signatures don't match | Discard the webhook body and return a 400 HTTP(S) status code. |
| No signature received (and you are set up for HMAC) | Return a 400 HTTP status code. |
HMAC signature string comparison should be done in constant-time to prevent potential timing attacks.
Due to our security policies, the key we use for generating HMAC signatures is subject to periodic renewal. We will contact you regarding to key renewal process.
The key renewal must allow you to continue to validate signatures during the renewal process without experiencing downtime or incorrectly rejecting notifications. The old key will therefore also be available for signature validation during the renewal process.
We will contact you in order to share the key through a secure channel.
The requests will contain 2 signatures
- one signature with the current key which is about to be decommissioned
- a second signature with the key previously received which you verify again
From the moment the signatures generated with the new key are validated and ready to be used, the old key can be decommissioned.
Once your new key is working you must notify your Implementation Manager to confirm the switch from old signatures validation exclusively to the new key. We can then permanently deactivate the old key.