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 owneryou are not allowed to use forms
error 103: inactivethe selected form is inactive
error 104: not api owneryou are not allowed to use the form api
error 105: no hashform hash is missing
error 106: no configno form has been found for the given hash
error 202: session processedprocessed sessions cannot be read or updated
error 203: session not foundwrong or no session hash at updateSession
error 204: session exists alreadyhash of existing session used for createSession
error 205: new session requires valuesyou 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.