Tikkie Payment Request

Get paid faster by creating easy payment requests. Share them via any channel you want.

Functional Details

To use the Tikkie API, you have to first create a platform and add some users. Then, you can generate payment requests on behalf of these users and later access these payment requests. In the text below the general concepts of platforms, users and payment requests are explained in more detail.


Please note that there will be different thresholds on different aspects of payment requests like number of payments per payment request, maximum amount of a payment request etc. These thresholds will be discussed on a per customer basis during onboarding. In Sandbox environment, these thresholds are not applicable.


To gain access to the PR API on the developer portal, create an App and get API credentials. For API credentials, you will first have to sign a Tikkie contract. When you have signed this contract, you will also receive login credentials for the Tikkie portal. All Tikkies created with the API will be visible in this portal. After this, create a platform in the API and send your platformtoken to us. We will link your platform to your portal and create an API user in your platform. With this user, you will be able to create business Tikkies, which are linked to your portal settings (such as thresholds and nice GIFs).

POST Platform

This operation creates a new platform. The platform is a container for users from whom you can initiate payment requests. Details of the new platform should be provided in the payload. At least the name of the new platform and a phone number of a contact person should be there (currently only Dutch phone numbers are supported), but it may also include an e-mail address and/or a notification url.

For the platform two types of usage can be specified:

  • PAYMENT_REQUEST_FOR_MYSELF, a request sent from the business to its client to pay for his obtained purchase.
  • PAYMENT_REQUEST_FOR_OTHERS, a request generated by the business for the client to send it to one of his friends to split the bill. Please note: Currently not available.

For example. Client books a hotel at the hotel's website and pays this via Tikkie (PAYMENT_REQUEST_FOR_MYSELF). However, the client will be staying at the hotel with his friend, who will pay half of the bill. The client can now request a Tikkie request from the hotel to send to his friend. The hotel will generate a PAYMENT_REQUEST_FOR_OTHERS and sends this to the client. The client will then send this Tikkie request to his friend so that the friend can pay him back (on the client's IBAN).

If the enrollment of the new platform is successful, a platform token will be provided that can be used to access the platform in the future.

GET Platforms

This operation will fetch all platforms created for a certain API consumer.


In your platform you can have multiple users from whom you can initiate payment requests. This operation enrolls new users into an existing platform. The platform is identified by a platform token. The details of the new user should be provided in the payload. These include the name and phone number of the user, but also an IBAN account number and a label specifying the type of account. This account will be coupled to this users and is used in future payment requests. Please note: at the moment only Dutch phone numbers and IBANs are accepted.

Upon a successful enrollment, a user token and a bank account token will be provided that can be used to access this user in the future.

GET Users

This operation will fetch all users created on a platform for a certain API consumer.

POST Payment request

Payment requests are initiated by a specific user from your platform. The recipient of the request has no role in the Tikkie API. The Tikkie API produces a link that can be send to the entity that should fulfil the payment request.

This operation creates a new payment request. The user and the bank account on behalf of whom the request is sent are specified by the user token and bank account token which should be provided in the path. The details of the actual request are provided in the payload. These include currency, amount and a description. If the creation of the payment request is successful, it will return a payment token for future access and a payment url that can be send to the user. The returned payment URL will direct to the tikkie website where the user can initiate the actual payment.

GET User payment requests

This operation will fetch all payment requests for a certain user. Identification of the requested user happens on the basis of a user token. The results will be paginated on the basis of the request, which should specify the number of requests and which record is the first in the batch. Filtering is optional and is currently only possible on the basis of date. The result of the operation is one page of payment requests. For each payment request a list of details is provided, such as the amount, currency, creation date, status. It also includes a list of the payments that have been done to fulfill this payment request.

GET Payment request

This operation will fetch a single payment request. The request is specified based on the provided payment token. As a result, the details of that payment request are shown. This details include amount, currency, creation date and status. It also includes a list of the payments that have been done to fulfill this payment request.

The payment status can have following possible values:

  • OPEN: The payment request can still be paid.
  • CLOSED: The payment request has been closed.
  • EXPIRED: The payment request has expired. The default expiry days is 14 days, but this is customizable when you start using the Production Tikkie API (We can change the expiry if needed).
  • MAX_YIELD_REACHED: The payment request has reached its max amount in €. The limit depends on the limit that is agreed upon.
  • MAX_SUCCESSFUL_PAYMENTS_REACHED: The payment request has reached its max amount of payments. The max amount of payments per request can be set 1 or unlimited.