Which payment methods can I start via the API?
There are two ways to have a booking paid via the API. Which one you can use depends on the payment provider of the environment. This page describes both routes, the allowed values for method, and what the error messages mean.
Route 1: the payment link (works with every provider)
A successful booking/add returns a payment_link field alongside the booking number, as soon as the payment module is active:
https://<jouw-omgeving>/front?mod=payments&booknumber=1234
Send the visitor to that link. They land on the i-Reserve payment page, choose a payment type there and are forwarded to the provider. This works with every payment provider set up in the environment, and you do not have to build a payment form yourself. For most integrations this is the route to take.
Route 2: the checkout call (limited availability)
If you want to build the payment form yourself, you can request the provider's fields:
POST api/rest/payment/booking
{
"booking_id": 1234,
"method": "BUCKAROO"
}In version 2 of the API the booking number sits in the path: POST api/rest/v2/payment/booking/1234/checkout, with only {"method": "BUCKAROO"} in the body. For an invoice, payment/invoice works the same way.
Note: this call is not implemented for every provider — see the Implemented column in the table below. Providers without an implementation answer with {"message": "Not implemented"}. If you get that back, your call is not wrong: that provider simply has no checkout via the API. Use route 1 instead. Because Ingenico and Ogone are being phased out, Buckaroo is in practice the provider you pick for this route.
Allowed values for method
The value is the name of the payment provider, not of a payment type such as iDEAL or Bancontact. Which payment types the customer gets to see is decided by the provider in its own checkout. The value is not case sensitive.
| method | Payment provider | Implemented | Remark |
|---|---|---|---|
INGENICO | Ingenico (Worldline) | Yes | Being phased out |
OGONE | Alias for Ingenico, the former name Ogone | Yes | Being phased out |
BUCKAROO | Buckaroo | Yes | |
MOLLIE | Mollie | No | Use the payment link (route 1) |
CARDGATE | CardGate | No | Use the payment link (route 1) |
STRIPE | Stripe | No | Use the payment link (route 1) |
PAYDOT | Pay. (formerly Pay.nl) | No | Use the payment link (route 1) |
Note that Pay. is called as PAYDOT. i-Reserve does not recognise PAYNL or PAY.NL.
Payment types that i-Reserve administers itself — cash, card terminal, PayPal, punch card and payment on account — have no online checkout, so you cannot start them with this call.
method or pay_id
- method — use this in the normal case. i-Reserve looks up the first active payment setting for that provider itself, within the licence the booking belongs to.
- pay_id — the number of one specific payment setting, found under Configuration > Modules > Payment settings. Use it only when you have several settings for the same provider and know exactly which checkout you want.
If the request carries a pay_id greater than 0, method is ignored. So leave pay_id out, or at 0, as long as you work with method.
Error messages
| Code | Message | Meaning |
|---|---|---|
| 200 | {"message": "Not implemented"} | This provider has no checkout via the API. Use the payment link from booking/add. |
| 412 | No valid method could be found | The method you supplied is not in the table above. Check the spelling. |
| 404 | Cannot find payment config for method [X] | The method is valid, but this environment has no payment setting for that provider at all. If the setting exists but is incompletely filled in, you do not get this message. |
| 412 | No valid booking_id could be found | The request carries no booking number. |
| 404 | Booking id supplied but not found | The booking number you supplied does not exist. |
| 412 | The invoice is not final | Only a final invoice can be paid. |






