If we cannot deliver a webhook to your server, it goes to the retry queue, and you can troubleshoot the issue with the information we provide.
Check that your server can receive and acknowledge our webhooks. Incorrect server setup is a common cause of failure to deliver webhooks.
To access the list of webhooks that encountered an error during delivery in your Customer Area:
- Go to Developers > Webhooks. Webhooks that we didn't successfully deliver to your server have a Failing status.
- Select the webhook with the Failing status from the list.
- Select the Troubleshoot button to troubleshoot the issue.
Additionally, in your Customer Area, you can find a log of your webhook events.
Retry queue
Each webhook with the Failing status is in the retry queue. We retry sending the earliest webhook in the queue for 30 days, following these time intervals:
- 2 minutes
- 5 minutes
- 10 minutes
- 15 minutes
- 30 minutes
- 1 hour
- 2 hours
- 4 hours
- 8 hours
If we successfully deliver it to your server, we retry sending the next webhook in the queue.
If your server doesn't acknowledge webhook events, we send a notification in your Customer Area after the fifth retry. Subscribe if you want to get notifications by email.
Retry queues are separate for each endpoint. If you have more than one endpoint for receiving webhooks, troubleshoot them separately.
Troubleshoot the issue
Each webhook in the retry queue includes an error message that can help you troubleshoot the issue. Make changes to your endpoint and try to send the webhook again by selecting Retry , or remove the webhook from the queue by selecting Ignore notification .
AUTHORISATION webhooks for credit card payments that do not go through 3D Secure are sent from a different system that doesn't require your server to accept the webhook. Therefore, do not use this type webhook as an indication to troubleshoot.
Retry
When you select this, we send the webhook to your endpoint again. If your endpoint successfully receives the webhook, you get a success message. If it fails again, you get an error message.
It can take several hours for the retry queue to update. Therefore, a webhook in the queue that successfully gets delivered can stay in the queue for several hours before it gets removed.
Ignore notification
When you select this, the webhook event is permanently removed from the queue, and you cannot try to send it anymore.
Common issues
After you send retries to your server using the Customer Area, you can then view the resulting errors. The exact meaning of the error message depends on how your server is set up. If you are using HTTP response codes in the standard way, some common errors and their meaning are:
- 401: Unauthorized. Your server is refusing the connetion due to invalid credentials. Make sure basic authentication and HMAC are set up properly and consider rotating the credentials.
- 404: Not found. Your endpoint could not be accessed. Make sure your endpoint is accessible over a network and there are no firewall rules that block incoming traffic.
- 422: Unprocessable content. Your endpoint was accessed but your business logic denied processing the event. This could be due to validation logic on your endpoint. Make sure the event is accepted first before applying any validation. Adyen recommends accepting every webhook and performing business logic related to its contents after.
- 499: Too many requests. Your endpoint was accessed but your server is rate limiting the requests. This can happen after you fix a failing webhook because all of the missing events get sent in a short timeframe.
- 500: Internal server error. This is usually a generic error from your server. Check that the endpoint is available and the route is accepting traffic.