Push messages

Push messages

Each transaction-status change can be communicated to the merchant’s webshop system or other backoffice system by way of a push message. This message will be sent after the customer has completed the payment process and the bank or third-party payment processor has communicated the status to Buckaroo. It is however not always possible to communicate the definitive status of a transaction straight after the payment process has been completed. It is also possible that the status doesn’t end up in the normal payment process flow due to the fact that the consumer interrupted the payment process. In such cases, a push message can be used to communicate the transaction status. As soon as the status is known to Buckaroo, the push will automatically share this information with the webshop.

If the push fails, for example because the webshop system was temporarily not able to receive push messages, Buckaroo will automatically reattempt to send the push message. If the push messages still haven’t been received properly by the merchant’s website after three days, Buckaroo will stop sending push messages.


It is possible that a successful push message is performed more than once. Bear this in mind while processing the push message and do not automatically create a new order after each successful push.

Failed push

The push service will try to connect to the set push URL. This will probably be a script on your webshop. Or a regular page that can be opened in the browser. The push is considered successful after receiving a HTTP 200. When an error code appears after having tried to connect to the URL, the push service will interpret this as a push failure. Subsequently, a warning email can be sent to a specified email address. The push message will be sent once again at a later time. If, after a few attempts, the message still hasn’t been sent successfully, a concluding message can be sent. After that, no further attempts will be made to send the push. It is however still possible to send a push manually. For details, see the manual push. You can find a list of HTTP status codes on Wikipedia.

Push message repeats

If the push messages fail to be successful, new attempts will be made to send them. This might happen when a push notification wasn’t accepted or when the so-called listener wasn’t active. The push notification will be repeated with the following frequency:

5 minutes + 10 minutes + 15 minutes + 30 minutes + 1 hour + 2 hours + 4 hours + 8 hours + 8 hours + 24 hours + 24 hours. So that’s 11 reattempts in total.

With regard to the warning message following the first push fail and the concluding message following the final push, an email can be created in the Plaza.

Double push

A push could be performed twice or even more for a variety of reasons. This situation may occur because a consumer is clicking back and forth between the different payment screens. It is also possible that while executing the push, the push server doesn’t receive the correct answer from the webshop and therefore will make another attempt to send the push at a later time. So please bear in mind that your system can receive a push message more than once. The push timestamp however allows you to make a clear distinction between the different messages regarding the same transaction. So that you’ll be able to place them in the correct time line without a problem.


In some cases, two push messages are sent with the same timestamp. This can happen when a redirect is performed on both a desktop and a mobile device. This due to finishing the transaction using a bank App on the mobile device. In that case both redirects will cause a push message. In that case please check whether the infrastructure has a redundant handling for the listener service. Then it is necessary to guarantee the sequential handling of push messages originated from the same IP address. If this is not guaranteed, two actions can be performed next to each other, leading to duplicate orders or blocking actions in the processing database.

Push order

Because a failed push will be resent again with a certain delay, it’s possible several push messages cross each other. Thus, it might occur that a push about the temporary pending status of a transaction is sent after the definitive successful or failed status has already been communicated.

To avoid making any mistakes, always check the accompanying timestamp. The status of a push message with an earlier timestamp can never overrule the status of a push message with a later timestamp.

Push POST data (Push content type: httppost)

Element Description Optional
brq_payment The Payment key. This value is only communicated if a payment method was selected. Yes
brq_payment_method The service code of the method used for the payment. Yes
brq_statuscode The status code of the transaction. No
brq_statuscode_detail A detail status code which offers an additional explanation about the current status code. Yes
brq_statusmessage A message about the status code. Yes
brq_invoicenumber The invoice number given in the request. No
brq_amount_credit The credit amount as defined in the request, provided it was given. Yes
brq_amount The transaction amount, provided it is a debit transaction. Yes
brq_currency The currency of the transaction (for example EUR, USD, GBP). No
brq_timestamp The time at which the transaction received its current status. No
brq_service_[servicecode] _[parametername] Output parameters for the required services. Yes
cust_[parametername] The predefined custom variables accompanying the original request. Yes
add_[parametername] The additional parameters accompanying the original request. Yes
brq_transactions One or several transaction key(s). One key if one underlying transaction was created for the payment. Several keys if several underlying transactions are linked to the payment. No
brq_transaction_method The method used for the processing of the transaction (only when a transaction has already been processed). No
brq_transaction_type The transaction type code of the transaction (only when a transaction has already been processed). No
brq_mutationtype The mutation type of the transaction: collecting, processing, informational or notset. Yes
brq_signature The digital signature. No

IP addresses and port numbers

Push messages from Buckaroo to the Merchant can be sent from the following IP addresses:

IP range :

Since 01-10-2022, the push messages can also be sent from the following IP addresses:

Incoming traffic

Inbound IP addresses will be replaced with dynamic IP addresses managed by Amazon Web Services. It is undesirable to allow traffic from your systems to Buckaroo via an allow list because these IP addresses can always change without Buckaroo having any influence on this.


Sometimes test environments use other gateways to receive Buckaroo’s push messages. The following gateways are supported: 22; 44; 80; 8443; 8787; 8880; 8888.

Was this article helpful?

What's Next