OnlineFundraising is an API-first approach to offering a one-stop Payment Engine to NGOs. This means that though you may be familiar with OnlineFundraising as a webinterface all functionalities are also available as direct API calls. These pages aim to describe how you may integrate our API with your services.
To the left we have split our entities into what we consider the basic and extended use of our API which you may prefer configuring in our interface.
We recommend that you start by reading through the basic entities to gain an immediate understanding of how the data is structured. Afterwards you should begin by implementing the Contact, Agreement, Payment, and Subscription entity in your project, so you are able to listen for their related webhooks triggered at certain events and handle the data as you please. You may wish to limit your webhook listener to the entities and events relevant for your project.
If you are looking for deprecated API documentation, please visit these:
A quick link to our latest API documentation can be found at:
Get an OnlineFundraising Account
We also offer a free Sandbox with Test Data and Test Payment Solution. Please contact our offices on +45 3529 4855
Build a Form in OnlineFundraising
Configure a Data Receiver
Get an API key
Good to go
API key and IP address
Create your own API key in OnlineFundraising under Settings providing the IP address you will be connecting from.
Make sure to apply your API key in your HTTP Header:
HTTP Headers for POST requests must equally contain the request body as a MD5 JSON encoded string:
The agents you will get to know are:
The organisation or company using OnlineFundraising.
The Payment Gateway providing Payment Services accessed by OnlineFundraising.
The Payee and/or End User.
The User of OnlineFundraising with optionally different access levels.
OnlineFundraising's automatic Payment Solution.
The main entities are:
The Payee and/or End User.
Defines what is being paid, how often, from when, and how much.
Defines how payments are charged.
The connection between Agreement, Payment Method, and Contact representing the Contact's engagement of the Agreement.
Describes the individual Payment (single, one-off and recurring).
The relation between the main entities can be described with this diagram:
For old timers you may find an entity missing in the diagram above. We have chosen to deprecate a "Project" entity, which contained various informations on the type of Agreement and Payments, in favor of the following split responsibility:
Deprecated project property
Metadata stored on the related DataSet.
The Agreement property: "taxDeductable".
Fixation of amount
The Agreement property: "amount" accompanied by properties for quantity and VAT.
The Agreement property: "purposeAccountingCode" accompanied by the Payment property: "paymentMethodAccountingCode" which combined will help accounting keep track of transactions across purposes and payment methods.
Payment Session Handler
All data is sent and received as JSON, so please ensure a Content-Type: application/json; charset=utf-8 HTTP header is provided.
All entities carry a 128-bit globally unique identifier (GUID), such as: a863d62e-d53b-4651-9b7b-c80792ee1343
All timestamps are returned as yyyy-MM-dd HH:mm:ss Z in Europe/Copenhagen timezone, such as: 2019-12-31 15:59:59 +0100
Amounts use a 0.0 format, decimals separated with a dot. No thousand separator.
You may find the following resources helpful in your work:
DAWA - public API providing Danish address verification and sanitation
Download of DK post codes - static files
CVR API - public API for verification of Danish Business Codes
CPR explanation. Please see below for CPR validation and testing
HTTP Status Codes
OnlineFundraising will return the following HTTP Status Codes:
200 - OK
201 - Created
Resource was created as requested.
202 - Accepted
Request will be processed asynchronously.
400 - Bad Request
If request data is invalid.
404 - Not Found
If the resource cannot be found.
501 - Not Implemented
The service is not implemented.
500 - Internal Server Error
Something went really wrong in our end.
For error codes regarding entities, please see: Error and Cancel Codes
Testing with CPR
As your testning progress you may find yourself in need of this set of valid Danish NationalIDs (source sundhed.dk):
Valid Danish NationalIDs (CPR) for testing purposes
CPR validation in PHP
How do I skip a scheduled Payment?
You cannot skip a scheduled Payment directly, but you may send an Inactive request to a Subscription immediately followed by a Restart request containing a scheduleStartDate for the next scheduled Payment.
How do we keep track of UTM parameters?
Metadata such as UTM parameters submitted to OnlineFundraising will be kept in our DataSet.