With the Session-API you can store collected data into a session and use it to prepopulate your donation form or to process this session with the Payment-API. The sent values are immediately validated, so you can show errors to your user.

The Session-API is qualified for implementing custom apps with an own payment/donation step (e.g. a charity shop or a mobile donation app).

See app/createSession and app/updateSession for further informations.



We also provide a Javascript-jQuery-Plugin for easy implementation on your website.

1. Form Prepopulation

The Session-API allows a severside form data prepopulation. You submit form data before the form itself is loaded. In contrast to the simple Form-Prepopulation-API the data is not exposed to the public. For that reason you can also transfer non-public values like primary keys or complete data structure like shop baskets.
Another great advantage is that submitted values do not have any GET request size restriction, because you can POST the values to this endpoint.

Append the session hash of the JSON-result to your form url as GET-parameter.
All the values which you transferred to the session are then automatically prepopulated to the form.


Incomplete session are ok

For prepopulation it's not required that the session has the status "complete".


So the sent values are immediately validated, there can be errors on these. You have to consider and handle the "current_fields" error. For example if you submit an invalid email-address this value won't be stored in the session and you should show the error to your user.

Non editable prepopulation

Every value can be fixed, so the user cannot change or delete the value in the iframe payment form. Just add a "_fix" to the fieldname.
For example: payment[amount_fix]=12.34

2. Process with Payment-API

You can build up a session with a multi-step-form and process it with the Payment-API. In this case the session has to be complete.


You just have to provide the hash of your form, there is no secret authentication, because the donation form is a public part of your website. You can find the hash of your form in the settings of your form in your FundraisingBox.



On a successful API-request you get a JSON with HTTP status 200. Even if there are e.g. current_fields_errors on your session or the payment_status is "error", it was a successful request and it returns a JSON with status "success".

Only if there is an error preventing the API from working you get a JSON with status "error" and the corresponding HTTP error code, 400, 404 or 500.

  "status": "error",
  "error": "error 105: no hash"

Possible errors:



error 101: general error
error 900: general error

something went wrong, please contact our support

error 102: not owner

you are not allowed to use forms

error 103: inactive

the selected form is inactive

error 104: not api owner

you are not allowed to use the form api

error 105: no hash

form hash is missing

error 106: no config

no form has been found for the given hash

error 202: session processed

processed sessions cannot be read or updated

error 203: session not found

wrong or no session hash at updateSession

error 204: session exists already

hash of existing session used for createSession

error 205: new session requires values

you have to submit some values for createSession

error 404: server error
error 500: server error

something is wrong with the server

maintenance: ...translated maintenance message...

the FundraisingBox is currently in maintenance mode


Please not that when testing a form in sandbox mode, sessions also must be created correspondingly, using the correct sandbox hash.
See app/createSession and app/updateSession for further informations.