Setting the card Limit and changing the PIN code
Last updated
Was this helpful?
Last updated
Was this helpful?
In the last part we ordered a card that we want to lend to our friend. For this tutorial we want him to only make 1 purchase of maximum €100 and our friend can pick his own pincode.
Doing this is very simple using the PUT method on our cards endpoint.
We only have to pass the values we want to change. In our case we will chose a body like so:
This sets our pincode to 1234 (assuming that's the code our friend wants). And we set the limit on the card to €100 , and €0 for ATM withdrawels so our friend does not grab a bunch of cash. If you want to change other values (e.g. allowed countries or the monetary account connected then we can but it's outside of the scope for this tutorial).
After our friend made his card payment we would like to revert back to our own spending limits and our own pin code. We can do this simply by redoing the API call we just did and updating the body. So
The issue is more, how will we know when to make that call, as in the ideal situation for this tutorial we want to make it as soon as the card payment comes in. As with everything at bunq we can do this near instant.
The crude way of doing it is by polling our payments with the GET Paymentmethod, that returns a list of payments. There is a more sophisticated design pattern we could use which is using Callbacks. To set up callbacks we need to register a notification filter Notification Filter
Your app can subscribe to events that happen on the bunq API by using Callbacks (Webhooks). These are POST requests our server will make towards your server when an event happens.
One of the events we could listen to is CARD_TRANSACTION_SUCCESSFUL which will tell us about succesful card transactions. This is done by a POST request from bunq to a URL we specify (usually on our server).
To do this we can add a callback url by adding a notification filter url. And passing a body like:
This registers the URL and now bunq will call that endpoint everytime there's a successful card transaction. Your server will have to to check the card_idin the event to match it to the card ID that we borrowed our friend.
But if that matches you can simply make the API call that we did before, and revert to the pin_code and card_limits of your choice. And the card will be unusable by your friend after that.
]
Update the card details. Allow to change pin code, status, limits, country permissions and the monetary account connected to the card. When the card has been received, it can be also activated through this endpoint.
The standard HTTP Cache-Control header is required for all signed requests.
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.
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.
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.
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.
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.
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
The plaintext pin code. Requests require encryption to be enabled.
DEPRECATED: Activate a card by setting status to ACTIVE when the order_status is ACCEPTED_FOR_PRODUCTION.
The status to set for the card. Can be ACTIVE, DEACTIVATED, LOST, STOLEN or CANCELLED, and can only be set to LOST/STOLEN/CANCELLED when order status is ACCEPTED_FOR_PRODUCTION/DELIVERED_TO_CUSTOMER/CARD_UPDATE_REQUESTED/CARD_UPDATE_SENT/CARD_UPDATE_ACCEPTED. Can only be set to DEACTIVATED after initial activation, i.e. order_status is DELIVERED_TO_CUSTOMER/CARD_UPDATE_REQUESTED/CARD_UPDATE_SENT/CARD_UPDATE_ACCEPTED. Mind that all the possible choices (apart from ACTIVE and DEACTIVATED) are permanent and cannot be changed after.
The order status to set for the card. Set to CARD_REQUEST_PENDING to get a virtual card produced.
ID of the MA to be used as fallback for this card if insufficient balance. Fallback account is removed if not supplied.
The user's preferred name as it will be on the card.
The second line of text on the card
The reason for card cancellation.
Manage the url notification filters for a user.
The standard HTTP Cache-Control header is required for all signed requests.
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.
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.
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.
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.
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.
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