Purpose

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.

📘
Form-API
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.

http://www.mynonprofit.com/donation?fbSessionHash=abc12345

📘
Incomplete session are ok
For prepopulation it's not required that the session has the status "complete".

Errors

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.

Authentication

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.

Errors

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	Description
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

Sandbox

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.