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.
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.
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.
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_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 : 126.96.36.199/27
Since 01-10-2022, the push messages can also be sent from the following IP addresses:
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.