Session-API
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.