Payment Service Provider Issuer Transaction
The Payment Service Provider Issuer Transaction enables you to initiate a payment to any bank account of your choice. This feature is particularly useful if you want to allow bunq users to pay directly through your platform while providing a seamless, branded experience via a bunq-hosted payment portal—without relying on third-party payment providers. The typical flow works as follows: Create the payment You start by sending a POST request to the endpoint, including essential details such as the payment amount, a redirect URL, and the counterparty information. This request sets up the payment and its parameters in the bunq system.
Receive the payment ID The response will include a unique ID for the transaction. This ID allows you to retrieve the full details of the payment at any time using a GET request.
Retrieve the public UUID From the payment details response, you should capture the public_uuid. This identifier is necessary to generate the direct link to the bunq payment portal.
Redirect your user Once you have the public_uuid, you can redirect your users to the payment portal using the following URL structure:
For sandbox use: https://psp.triage.bunq.com/?transactionId=<public_uuid>
For Production https://psp.bunq.com/?transactionId=<public_uuid>
This portal provides a secure and user-friendly interface for completing the payment. Handle post-payment After the user completes the payment, they will be redirected to the URL you specified in the original request. You can then make another GET request to fetch the latest status and details of the payment, such as the payer information, payment status, and any other metadata.
This flow ensures that payments are both secure and easy to integrate into your platform, giving your users a smooth and reliable experience from initiation to completion.
Transaction statuses
A transaction moves through the following statuses during its lifecycle:
CREATED
Transaction initiated by the PSP. No user interaction yet.
CLAIMED
A bunq user has opened or claimed the transaction.
ACCEPTED
The bunq user approved the payment. This is the terminal success state.
REJECTED
The user declined the payment.
CANCELLED
The PSP cancelled the transaction before the user acted.
EXPIRED
The transaction timed out without a decision.
The typical lifecycle is:
CREATED (after PSP creates the transaction)
CLAIMED (when a bunq user opens the payment portal)
ACCEPTED / REJECTED / CANCELLED / EXPIRED (terminal state)
Note: there is no COMPLETED status. ACCEPTED is the final state indicating the payment was approved.
This is the body you'll POST notice the expiry time
This is the object you'll get returned when you do the GET request
Last updated
Was this helpful?