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": "[e-mail]",
                "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.

post

Create a new Payment.

Path parameters

userIDintegerRequired

monetary-accountIDintegerRequired

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

Body

descriptionstringOptional

The description for the Payment. Maximum 140 characters for Payments to external IBANs, 9000 characters for Payments to only other bunq MonetaryAccounts.

merchant_referencestringOptional

Optional data included with the Payment specific to the merchant.

allow_bunqtobooleanWrite-onlyOptional

Whether or not sending a bunq.to payment is allowed.

idintegerRead-onlyOptional

The id of the created Payment.

createdstringRead-onlyOptional

The timestamp when the Payment was done.

updatedstringRead-onlyOptional

The timestamp when the Payment was last updated (will be updated when chat messages are received).

monetary_account_idintegerRead-onlyOptional

The id of the MonetaryAccount the Payment was made to or from (depending on whether this is an incoming or outgoing Payment).

typestringRead-onlyOptional

The type of Payment, can be BUNQ, EBA_SCT, EBA_SDD, IDEAL, SWIFT or FIS (card).

sub_typestringRead-onlyOptional

The sub-type of the Payment, can be PAYMENT, WITHDRAWAL, REVERSAL, REQUEST, BILLING, SCT, SDD or NLO.

bunqto_statusstringRead-onlyOptional

The status of the bunq.to payment.

bunqto_sub_statusstringRead-onlyOptional

The sub status of the bunq.to payment.

bunqto_share_urlstringRead-onlyOptional

The status of the bunq.to payment.

bunqto_expirystringRead-onlyOptional

When bunq.to payment is about to expire.

bunqto_time_respondedstringRead-onlyOptional

The timestamp of when the bunq.to payment was responded to.

batch_idintegerRead-onlyOptional

The id of the PaymentBatch if this Payment was part of one.

scheduled_idintegerRead-onlyOptional

The id of the JobScheduled if the Payment was scheduled.

Responses

200

Using Payment, you can send payments to bunq and non-bunq users from your bunq MonetaryAccounts. This can be done using bunq Aliases or IBAN Aliases. When transferring money to other bunq MonetaryAccounts you can also refer to Attachments. These will be received by the counter-party as part of the Payment. You can also retrieve a single Payment or all executed Payments of a specific monetary account.

application/json

400

This is how the error response looks like for 4XX response codes

application/json

post

HTTPcURLJavaScriptPython

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
}