First Payments
In the previous chapter you already made a request to Sugar Daddy to get money on your sandbox account and you made API calls to retrieve the balance on your accounts. If you have that implemented in your application you're already well on your way to manipulate the majority of objects in the bunq API. We highly recommend you take a look at API Reference to see all the endpoints we offer.
But before we let you go we have to get to the good stuff: making a payment. The reason we make it a separate topic is that we got quite some feedback that people get stuck on something called 'signing'.
What is signing and why does it matter
In short: if you use our API to make a payment you don't want a man-in-the-middle to be able to meddle with your request. If you made a payment for let's say €10, then you don't want anyone to hijack that request and make the payment €12. Signing prevents that from happening as we create a signature that allows the bunq backend to validate that the content of the request has not been tampered with. You can read much more about signing here Signing. In this tutorial we'll just show you how.
Making a Payment
The API call for making a payment is nothing special (except for the signing) so you can just make a call using the method described below.
Some points of attention:
The counterparty is a pointer towards a user bunq API Objects
You can construct your own using json
{
"amount": {
"value": 10,
"currency": "EUR"
},
"counterparty_alias": {
"type": "EMAIL",
"value": "[email protected]",
"name": "Sugar Daddy"
},
"description": "here is your money back"
}
Signing
Now one of the things we need to do before we can actually make the API call is to generate a signature and add it to our `'X-Bunq-Client-Signature' in the header of the API call.
The specifics on how to do that are in Signing on that page you'll also find some coding examples. For instance in python Full signing.py
From there it's nothing different than a normal API call and you just post to the endpoint and will receive a ID of the generated payment.
Create a new Payment.
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 description for the Payment. Maximum 140 characters for Payments to external IBANs, 9000 characters for Payments to only other bunq MonetaryAccounts.
Optional data included with the Payment specific to the merchant.
Whether or not sending a bunq.to payment is allowed.
The id of the created Payment.
The timestamp when the Payment was done.
The timestamp when the Payment was last updated (will be updated when chat messages are received).
The id of the MonetaryAccount the Payment was made to or from (depending on whether this is an incoming or outgoing Payment).
The type of Payment, can be BUNQ, EBA_SCT, EBA_SDD, IDEAL, SWIFT or FIS (card).
The sub-type of the Payment, can be PAYMENT, WITHDRAWAL, REVERSAL, REQUEST, BILLING, SCT, SDD or NLO.
The status of the bunq.to payment.
The sub status of the bunq.to payment.
The status of the bunq.to payment.
When bunq.to payment is about to expire.
The timestamp of when the bunq.to payment was responded to.
The id of the PaymentBatch if this Payment was part of one.
The id of the JobScheduled if the Payment was scheduled.
POST /v1/user/{userID}/monetary-account/{monetary-accountID}/payment HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Content-Type: application/json
Accept: */*
Content-Length: 162
{
"amount": {
"value": "text",
"currency": "text"
},
"counterparty_alias": {},
"description": "text",
"attachment": [
{
"id": 1
}
],
"merchant_reference": "text",
"allow_bunqto": true
}{
"id": 1
}Last updated
Was this helpful?