# Webhook
### **Introduction**
**Webhooks** are HTTP callbacks that notify you of all *events* you subscribed for on an entity.
**Events** can be payments, state changes to payments or transactions connected to a payment (e.g. a chargeback).
For PCI compliance, SSL connections using untrusted certificates are not allowed. Please ensure you have a valid SSL certificate chain. Self-signed certificates are not valid.
**Availability**
| Title | Title |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Delay** | Near real-time. [*What does near real-time mean?*](https://en.wikipedia.org/wiki/Real-time_computing#Near_real-time) |
| **Request timeout** | 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** | Every day you would receive an summarized email with the newest 100 failed notifications sent to the list of emails configured for this listener. The notifications that were queuing up for the last thirty days will be deleted. You still can get these contents by using the other reporting tools of the platform. |
| **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. |
### **Setup**
**To setup the webhook for you, please provide your Account Manager or Sales Representative with the following information:**
| URL | The URL that receives the notifications. It has to be https |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Notification types | The notification types you want to subscribe to. E.g. by selecting PAYMENT the registered URL will receive all payment events happening on this entity and its descendants. You can choose any subset of the available options. |
| Fields to include | The fields you want to receive in payload. E.g. by selecting ALL, payload will include every fields the transaction generates.
- ALL Payload includes all fields the transaction generates
- NON\_CUSTOMER\_DATA Payload includes only fields which are not customer data
|
| Wrapper | If you need to get specific content type for webhooks, you can choose wrapper for it.
- None No wrapper for webhook body. Content-Type will be text/plain and body will be (encrypted) hexadecimal string.
- JSON Json wrapper for webhook body. Content-Type will be application/json and body will be wrapped by json example: {"encryptedBody":"\[(encrypted) hexadecimal string]"}
|
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://developers.primeiropay.com/webhook-1.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.