Push messages
Buckaroo can communicate transaction status changes to your webshop or back-office system via push messages. This happens after the payment process is completed and the status is known. Interruption of payment by the customer or delays/outages at underlying banks can cause communication to be delayed.
Push failure and reattempts
If the push fails, for example, because the webshop system was temporarily unable to receive or process push messages, Buckaroo will automatically reattempt to send the push message. If the push messages have not been received properly by the merchant’s website after three days, Buckaroo will stop sending push messages.
Important
A successful push message might be sent more than once. Do not automatically create a new order after each successful push.
Failed push
The push service calls the set push URL, which can be a script on your webshop or a normal page that can be opened in a browser. The push is successful when receiving an HTTP 200. If calling the URL results in an error code, the push service interprets this as a failure. In the Buckaroo Plaza, under the Logs tab, you can find the history of all push attempts, including any error messages. You can set up a warning email under Settings > Websites > Push settings > E-mail push failure. A warning email is sent for the first and last failed push. It is also possible to perform the push manually by selecting the relevant transaction in the Plaza and resending the push via the Actions button.
Push message repeats
If push messages fail to be successful, new attempts will be made. This might happen when a push notification is not accepted or when the listener is not active. There are 11 reattempts in total, spread over 3 days. A warning message following the first push failure and a concluding message following the final push can be created in the Plaza.
Double push
A push could be performed multiple times due to reasons like a consumer clicking back and forth between different payment screens or the push server not receiving the correct answer from the webshop. Be prepared to handle duplicate push messages. The push timestamp allows you to distinguish between different messages for the same transaction, ensuring correct chronological order.
Note
In some cases, two push messages might be sent with the same timestamp, especially when using a bank app on a mobile device. Ensure your infrastructure can handle the sequential processing of push messages from the same IP address to avoid duplicate orders or blocking actions.
Push order
Because a failed push will be resent with a delay, several push messages might cross each other. Always check the accompanying timestamp. The status of a push message with an earlier timestamp should not 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 |
| brqservice[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. Avoid allowing traffic to Buckaroo via an allow list as these IP addresses can change without notice.
Ports
Supported gateways for test environments to receive Buckaroo’s push messages:
- 22
- 80
- 443
- 8443
- 8787
- 8880
- 8888
Bulk push
To push multiple transactions at once, use the Bulk Push feature in the Buckaroo Plaza. Navigate to Transactions > Overview, and use the Filters option to filter the transactions that need to be pushed again. Press Actions > Bulk Push. A screen will show all transactions within the filter range, allowing you to exclude individual transactions that do not need to be pushed again.
Updated 16 days ago