Set up and test your notifications server.
Here we take you through the process of setting up Standard notifications. These are required for your integration with the Adyen payments platform.
For this, you will need a server that can receive notifications, and accept them. Before going live, you'll also want to test your notifications setup.
You can additionally set up notifications to inform your server of pending payments, or integrate your reports with third-party systems. For more information, see Other notifications.
Step 1: Receive notifications
Notifications are sent as HTTP callbacks (webhooks) to endpoints on your server.
Set up a server that has the following:
- An endpoint that can receive a JSON or SOAP call, or HTTP POST.
- A username and password. The Adyen payments platform will use this for HTTP authentication.
- An open port:
|80||TCP||HTTP||Default port for HTTP traffic|
Default port for HTTPS traffic
Notifications are sent to your server with the details of a payment, modification, or report. Each notification contains an
eventCode, indicating which event has occurred.
The notification will also include other fields that contain the details of the transaction. For more information on what these mean, see our Notifications API reference.
The following example shows a successful authorisation for a 5.00 euro payment made with a Visa card.
For added security, you can enable HMAC signed notifications. This lets you verify that notifications weren't modified during transmission. For more information, see Signing notifications with HMAC.
Step 2: Accept notifications
To confirm that you have received a notification, your server should acknowledge the notification with the response:
We use at-least-once delivery to ensure that your server has received a notification. If your server has not acknowledged a notification within 10 seconds we will queue all notifications to this endpoint. We'll then retry sending the notification until it is accepted. Once accepted, you'll receive all your queued notifications.
Retry attempts will happen regularly, at increasing time intervals:
- 2 minutes
- 5 minutes
- 10 minutes
- 15 minutes
- 30 minutes
- 1 hour
- 2 hours
- 4 hours
Retries then happen every 8 hours for the following 7 days. You can also trigger a retry attempt by sending a test notification. For details, see Step 4: Test your notifications server.
Unaccepted notifications will cause your notifications to queue. We recommend persisting and accepting a notification before evaluating the notifications content. This will help to prevent notifications from queue.
When your server receives a notification:
- Store the notification. Ensure you have successfully persisted the message.
- Accept the notification. Respond with the appropriate accept response.
- Process the notification. If your system is unable to parse a notification, this should trigger an investigation by your technical team but not cause you to reject or not accept a notification.
In some cases, you'll receive an authorisation notification twice. These have the same values in the
pspReference fields. In this case, your server should use the details contained in the latest notification.
Step 3: Configure notifications in the Customer Area
Additional shopper and transaction information
You can also receive additional information about the shopper or transaction.
For more information, see Additional settings.
- Go to your Customer Area > Account > Server communication.
- Next to Standard Notification, click Add.
- Under Transport, enter your server's:
- SSL Version
- Communication Method (JSON, SOAP, or HTTP POST).
- Under Authentication, enter the User Name and Password.
- Click Save Configuration.
Step 4: Test your notifications server
Before going live, you’ll want to test your notifications configuration:
- In your Customer Area, go to Account > Server Communication.
- Click Edit & Test next to Standard Notification.
- Under Test Notifications, toggle which events you want to test.
- Click Test Configuration.