Push messages
Push messages
Article Summary
Share feedback
Thanks for sharing your feedback!
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.
Important
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.
Note
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:
3.70.163.111
3.70.110.167
3.126.45.67
3.72.131.8
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.
Ports
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?