Usage
Creating an API context
In order to start making calls with the bunq API, you must first register your API key and device, and create a session. In the SDKs, we group these actions and call it "creating an API context". There are two ways to do it. One is through our interactive script, and the other is programmatically from your code.
src/Util/InstallationUtil.php
Creating an API context using bunq-install interactive script
After installing bunq SDK into your project, run the command below from your project root folder:
$ vendor/bin/bunq-installAnd then follow the steps the script offers.
Creating an API context programmatically
The context can be created by executing the following code snippet:
use bunq\Context\ApiContext;
use bunq\Util\BunqEnumApiEnvironmentType;
use bunq\Util\InstallationUtil;
// Automatically install and save the API context
InstallationUtil::automaticInstall(
BunqEnumApiEnvironmentType::SANDBOX(), // Use PRODUCTION() for production
'/path/to/save/context.conf'
);Load the API Context:
Please note: initializing your application is a heavy task and it is recommended to do it only once per device.
PSD2
It is possible to create an ApiContext as PSD2 Service Provider. Although this might seem a complex task, we wrote some helper implementations to get you started. You need to create a certificate and private key to get you started. Our sandbox environment currently accepts all certificates, if these criteria are met:
Up to 64 characters
PISP and/or AISP used in the end.
Make sure you have your unique eIDAS certificate number and certificates ready when you want to perform these tasks on our production environment.
Creating a PSD2 context is very easy:
This context can be saved the same way as a normal ApiContext. After creating this context, create an OAuth client to get your users to grant you access. For a more detailed example, check the tinker_php repository.
Proxy
You can use a proxy with the bunq PHP SDK. This option must be a string. This proxy will be used for all requests done with the context for which it was provided. You will be prompted to provide a proxy URL when using the interactive installation script.
Safety considerations
The file storing the context details (i.e. bunq.conf) is a key to your account. Anyone having access to it is able to perform any Public API actions with your account. Therefore, we recommend choosing a truly safe place to store it.
If you rather save the context in a database, you can use the fromJson() and toJson() methods.
Making API calls
There is a class for each endpoint. Each class has functions for each supported action. These actions can be create, get, update, delete and listing.
Before you can start making calls, you must ensure that you have create an ApiContext and loaded in into BunqContext as shown in the examples above.
The SDK will take care of your user Id, as this id will never change per ApiContext. The SDK also uses your first active monetary account as primary monetary account. This is almost always the same as your billing account. This means that when you do not explicitly pass a Monetary Account ID, the SDK will use the Monetary Account ID of your billing account.
Basic Operations
Monetary Accounts
Create a monetary account:
Get account details:
Close a monetary account:
Payments
Make a payment:
Make a payment to another monetary account:
Batch Payments
Payment Requests
Create a payment request:
Accept a payment request:
bunq.me
Create a bunqme tab:
Attachments
Create a public attachment:
Get attachment content:
Avatar
Create an avatar:
Cards
Get allowed card names:
Order a debit card:
Notifications (webhooks)
Create notification filters for a monetary account:
Create notification filters for a user:
Create push notification filters:
OAuth
Create OAuth authorization URI:
Session Management
Delete a session:
Reset a session:
User Context Helper Methods
Reading objects
To use the read method you must pass the identifier of the object to read (ID or UUID) except for the endpoints User, UserPerson, UserCompany and MonetaryAccount. The SDK will use the default IDs when none are passed. For all other endpoints you must pass the identifier.
This type of calls always returns a model.
Updating objects
Deleting objects
Listing objects
Last updated
Was this helpful?