General Information

Introduction
Webhooks are HTTP Server-to-Server callbacks which notify you of post-transactional event such as chargebacks (CB), chargeback reversals (CR), and receipts (RC).
Availability
​
​
Delay                                                                                           
Near real-time
Request timeout
In order to acknowledge the receipt of the IPN, the system expects to receive an "200 OK" answer. If we don't receive a response within 30 seconds, the message is considered timed out. It will then be scheduled for retry.
Retries
 In case of a failed delivery we store a failed notification for a limited period of time and try sending it again later. 
Retries are sent at increasing time intervals until either the message is accepted or the maximum retry period of 30 days has been exceeded. After this time the transaction still can be looked up via the reporting endpoints or the BIP.

Retry-intervals:
1 minute
2 minutes
4 minutes
8 minutes
15 minutes
30 minutes
1 hour
every hour until 30 days have passed since the first attempt.
Beyond the retry period
If your server for receiving notifications does not accept one or more messages for more than five days then the webhook will be deactivated. Even if a single message is not accepted, that single message will be retried for 5 days and then the IPN will be deactivated, even though other messages have been accepted.
The notifications that were queuing up for the last five days will be deleted by the deactivation. You still can get these contents by using the other reporting tools of the platform.
The IPNs can be reactivated once you're back up, see configuration section.
Guarantee on message order
 There is no guarantee on the order of messages. If you first send request A and then request B, you might retrieve a notification first on B then on A, especially if...
The time difference between the messages is smaller than the time it takes us to process them
The receiving server was unavailable for a time. Once the server is up again new notifications will arrive in real time, old notifications however would only be resent once they are retried in the rhythm as specified above.
Required Client server power
Please make sure that your server for receiving notifications is able to properly receive the peak-loads that can be caused by the transaction processing on entities you're listening to. Example: If there is a transaction processing peak of 30 transactions/second then you would receive around 30 notifications/second on your webhook URL as well. We recommend asynchronous processing and a receiver cache for scenarios like this.

Last modified 4yr ago


Delay	Near real-time
Request timeout	In order to acknowledge the receipt of the IPN, the system expects to receive an "200 OK" answer. If we don't receive a response within 30 seconds, the message is considered timed out. It will then be scheduled for retry.
Retries	In case of a failed delivery we store a failed notification for a limited period of time and try sending it again later. Retries are sent at increasing time intervals until either the message is accepted or the maximum retry period of 30 days has been exceeded. After this time the transaction still can be looked up via the reporting endpoints or the BIP. Retry-intervals: 1 minute 2 minutes 4 minutes 8 minutes 15 minutes 30 minutes 1 hour every hour until 30 days have passed since the first attempt.
Beyond the retry period	If your server for receiving notifications does not accept one or more messages for more than five days then the webhook will be deactivated. Even if a single message is not accepted, that single message will be retried for 5 days and then the IPN will be deactivated, even though other messages have been accepted. The notifications that were queuing up for the last five days will be deleted by the deactivation. You still can get these contents by using the other reporting tools of the platform. The IPNs can be reactivated once you're back up, see configuration section.
Guarantee on message order	There is no guarantee on the order of messages. If you first send request A and then request B, you might retrieve a notification first on B then on A, especially if... The time difference between the messages is smaller than the time it takes us to process them The receiving server was unavailable for a time. Once the server is up again new notifications will arrive in real time, old notifications however would only be resent once they are retried in the rhythm as specified above.
Required Client server power	Please make sure that your server for receiving notifications is able to properly receive the peak-loads that can be caused by the transaction processing on entities you're listening to. Example: If there is a transaction processing peak of 30 transactions/second then you would receive around 30 notifications/second on your webhook URL as well. We recommend asynchronous processing and a receiver cache for scenarios like this.