Heya! Before checking this page, make sure that you in our API first.
As a PISP, you are allowed to authenticate in a user’s account with the following permissions:
read account information:
legal name;
IBAN;
initiate draft payments and read their statuses;
confirm that the account balance is sufficient for covering the payment.
The bunq API provides endpoints for different scenarios of the implementation of the payment initiation functionality. In particular, as a PISP user, you can build applications that initiate and authorize one-off or multiple incoming payments. Depending on the use case you are intending to deploy, you might need to initiate the OAuth authorization either before or after the payment initiation.
Authorization of multiple (scheduled) payments
It is possible to initiate payments from a bunq user's account having previously established an OAuth connection between your application and the bunq user's account. The bunq user will receive push notifications for each initiated payment.
Once a bunq user has , you can initiate the payment confirmation flow.
Create a draft payment via POST /user/{userID}/monetary-account/{monetary-accountID}/draft-payment
passing the following parameters:
monetary-accountId and userId (userApiKey's id; see for more information) in the endpoint URL;
the customer’s email address, phone number, or IBAN in the counterparty_alias field of the request body.
If the user confirms their intent to make the payment, bunq carries out the transaction.
Check the status of the payment via GET /user/{userID}/monetary-account/{monetary-accountID}/draft-payment
using the draft payment id parameter returned in the previous step.
Single payment authorization
It is possible to initiate payments having only the IBAN of the payer using POST /user/{userID}/payment-service-provider-draft-payment. In this case, the bunq user will accept the payment along with the authorization request. No additional push notifications are sent to the user.
Collect the bunq user's IBAN (and name) in the UI of your application.
Create a draft payment via POST /user/{userID}/payment-service-provider-draft-payment.
Check the status of the payment.
Get the end user information
You can get the user information by sending a calling the following endpoint with the user_id
If you have an open session on behalf of the user, just call GET /v1/user (with no user_id) to retrieve their info.
Confirm user account funds
You can check the availability of funds via POST /user/{userID}/confirmation-of-funds passing the following information:
your user_id;
the amount of money needed for the payment;
the name of the bunq user and the IBAN of the account (email address or phone number pointing at the user are also possible).
Here the full specs of this endpoint:
Initiate an Upon the QR-code scan, the bunq user will see and be able to either accept or reject the payment authorization request.
The standard HTTP Cache-Control header is required for all signed requests.
User-AgentstringRequired
The User-Agent header field should contain information about the user agent originating the request. There are no restrictions on the value of this header.
X-Bunq-LanguagestringOptional
The X-Bunq-Language header must contain a preferred language indication. The value of this header is formatted as a ISO 639-1 language code plus a ISO 3166-1 alpha-2 country code, separated by an underscore. Currently only the languages en_US and nl_NL are supported. Anything else will default to en_US.
X-Bunq-RegionstringOptional
The X-Bunq-Region header must contain the region (country) of the client device. The value of this header is formatted as a ISO 639-1 language code plus a ISO 3166-1 alpha-2 country code, separated by an underscore.
X-Bunq-Client-Request-IdstringOptional
This header must specify an ID with each request that is unique for the logged in user. There are no restrictions for the format of this ID. However, the server will respond with an error when the same ID is used again on the same DeviceServer.
X-Bunq-GeolocationstringOptional
This header must specify the geolocation of the device. The format of this value is longitude latitude altitude radius country. The country is expected to be formatted of an ISO 3166-1 alpha-2 country code. When no geolocation is available or known the header must still be included but can be zero valued.
X-Bunq-Client-AuthenticationstringRequired
The authentication token is used to authenticate the source of the API call. It is required by all API calls except for POST /v1/installation. It is important to note that the device and session calls are using the token from the response of the installation call, while all the other calls use the token from the response of the session-server call
Responses
get
GET /v1/user/{itemId} HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Accept: */*
Used to confirm availability of funds on an account.
Path parameters
userIDintegerRequired
Header parameters
Cache-ControlstringOptional
The standard HTTP Cache-Control header is required for all signed requests.
User-AgentstringRequired
The User-Agent header field should contain information about the user agent originating the request. There are no restrictions on the value of this header.
X-Bunq-LanguagestringOptional
The X-Bunq-Language header must contain a preferred language indication. The value of this header is formatted as a ISO 639-1 language code plus a ISO 3166-1 alpha-2 country code, separated by an underscore. Currently only the languages en_US and nl_NL are supported. Anything else will default to en_US.
X-Bunq-RegionstringOptional
The X-Bunq-Region header must contain the region (country) of the client device. The value of this header is formatted as a ISO 639-1 language code plus a ISO 3166-1 alpha-2 country code, separated by an underscore.
X-Bunq-Client-Request-IdstringOptional
This header must specify an ID with each request that is unique for the logged in user. There are no restrictions for the format of this ID. However, the server will respond with an error when the same ID is used again on the same DeviceServer.
X-Bunq-GeolocationstringOptional
This header must specify the geolocation of the device. The format of this value is longitude latitude altitude radius country. The country is expected to be formatted of an ISO 3166-1 alpha-2 country code. When no geolocation is available or known the header must still be included but can be zero valued.
X-Bunq-Client-AuthenticationstringRequired
The authentication token is used to authenticate the source of the API call. It is required by all API calls except for POST /v1/installation. It is important to note that the device and session calls are using the token from the response of the installation call, while all the other calls use the token from the response of the session-server call