Push messages

      Push messages

        Article summary

        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. Possible causes of this are that there is a delay or an outage at the underlying banks or, in the case of bank transfer transactions, the transaction is only set to the successful status once Buckaroo has received the funds from the consumer. 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 or process 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 calls the set push URL. This will be a script on your webshop. This can also be a normal page that can be opened in the browser. The push is considered successful when an HTTP 200 is received. When calling the URL results in an error code, the push service interprets this as the push having failed. In the Buckaroo Plaza, via the Logs tab, you can find the history of all push attempts, including any error messages. A warning email can be sent to an email address to be set. This can be set under Settings > Websites > Push settings > E-mail push failure. For the warning message, an email is sent for the first failed push and for the last failed push. It is also possible to perform the push manually. This can be done by selecting the relevant transaction in the Plaza and resending the push via the Actions button.

        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, spread over 3 days.

        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)

        brq_paymentThe Payment key. This value is only communicated if a payment method was selected.Yes
        brq_payment_methodThe service code of the method used for the payment.Yes
        brq_statuscodeThe status code of the transaction.No
        brq_statuscode_detailA detail status code which offers an additional explanation about the current status code.Yes
        brq_statusmessageA message about the status code.Yes
        brq_invoicenumberThe invoice number given in the request.No
        brq_amount_creditThe credit amount as defined in the request, provided it was given.Yes
        brq_amountThe transaction amount, provided it is a debit transaction.Yes
        brq_currencyThe currency of the transaction (for example EUR, USD, GBP).No
        brq_timestampThe 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_transactionsOne 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_methodThe method used for the processing of the transaction (only when a transaction has already been processed).No
        brq_transaction_typeThe transaction type code of the transaction (only when a transaction has already been processed).No
        brq_mutationtypeThe mutation type of the transaction: collecting, processing, informational or notset.Yes
        brq_signatureThe digital signature.No

        IP addresses and port numbers

        Push messages from Buckaroo to the Merchant can 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; 80; 443; 8443; 8787; 8880; 8888.

        Bulk Push

        It is possible to perform the push for multiple transactions at the same time. This can be done by navigating to Transactions > Overview in the Buckaroo Plaza. We recommend using the Filters option to filter beforehand on the transactions that need to be pushed again. You can then press Actions > Bulk Push.
        Subsequently, a screen will be shown of all transactions that have taken place within the filter range.
        In this overview you can still exclude individual transactions that do not need to be pushed again.

        Was this article helpful?

        What's Next