Callbacks are used to send real-time notifications on the events that happen on a bunq account. The updates information is sent to a URL of your choice.
To subscribe to specific events from a bunq account, you have to create notification filters. In practice, this means updating the UserPerson, UserCompany, MonetaryAccount or CashRegister object with notification_filters
.
Here is what the notification_filters
object looks like:
{
"notification_filters": [
{
"notification_delivery_method": "URL",
"notification_target": “{YOUR_CALLBACK_URL}",
"category": "REQUEST"
},
{
"notification_delivery_method": "URL",
"notification_target": "{YOUR_CALLBACK_URL}",
"category": "PAYMENT"
}
]
}
notification_delivery_method
: specify the delivery method:- URL (for sending an HTTP request to the provided URL). Choose this method to receive callbacks.
- PUSH (for sending a push notification to user's phone).
notification_target
: provide the URL you want to receive the callbacks on. This URL must use HTTPS.category
: specify the types of events you would like to receive callbacks on.
Category | Description |
---|---|
BILLING | notifications for all bunq invoices |
CARD_TRANSACTION_SUCCESSFUL | notifications for successful card transactions |
CARD_TRANSACTION_FAILED | notifications for failed card transaction |
CHAT | notifications for received chat messages |
DRAFT_PAYMENT | notifications for creation and updates of draft payments |
IDEAL | notifications for iDEAL-deposits towards a bunq account |
SOFORT | notifications for SOFORT-deposits towards a bunq account |
MUTATION | notifications for any action that affects a monetary account’s balance |
PAYMENT | notifications for payments created from, or received on a bunq account (doesn’t include payments that result out of paying a Request, iDEAL, Sofort or Invoice). Outgoing payments have a negative value while incoming payments have a positive value |
REQUEST | notifications for incoming requests and updates on outgoing requests |
SCHEDULE_RESULT | notifications for when a scheduled payment is executed |
SCHEDULE_STATUS | notifications about the status of a scheduled payment, e.g. when the scheduled payment is updated or cancelled |
SHARE | notifications for any updates or creation of Connects (ShareInviteBankInquiry) |
TAB_RESULT | notifications for updates on Tab payments |
BUNQME_TAB | notifications for updates on bunq.me Tab (open request) payments |
SUPPORT | notifications for messages received from us through support chat |
A Mutation is a change in the balance of a monetary account. A Mutation is created for each payment-like object, such as a request, iDEAL-payment or a regular payment. Therefore, the MUTATION
category can be used to keep track of a monetary account's balance change.
- Callbacks for the sandbox environment will be made from different IP's at AWS.
- Callbacks for the production environment will be made from 185.40.108.0/22.
The IP addresses might change. We will notify you in a timely fashion if such a change is planned.
When the execution of a callback fails (e.g. the callback server is down or the response contains an error), we try to resend it for a maximum of 5 times, with an interval of one minute between each try. If your server is not reachable by the callback after the 6th total try, the callback is not sent anymore.
We recommend that you use certificate pinning as an extra security measure. We will check if the certificate of the recipient server matches the pinned certificate that you provided and cancel the callback if the check fails or we detect a mismatch.
-
Retrieve the SSL certificate of your server using the following command:
openssl s_client -servername www.example.com -connect www.example.com:443 < /dev/null | sed -n "/-----BEGIN/,/-----END/p" > www.example.com.pem
-
POST
the certificate to thecertificate-pinned
endpoint.
Once ready, every callback will be checked against the pinned certificate that you provided. Note that if the SSL certificate on your server expires or is changed, our callbacks will fail.