To use the API, you need to generate an API key.
Normally, and especially during development, the API keys you have generated only have access to the organization they were originally created for, and doing all operations defined in the API reference on this site.
For special cases, and where the use case is relevant, we can support creating special partner keys, which can gain access to multiple organizations. This is useful for multi tenant cloud services, but less so for single tenant on premise installations.
If your API keys have enabled support for multiple organizations, it is required to use the X-Organization-Id header on the endpoints where this is noted. You can either fetch the IDs of each organization through the portal or you can use a special endpoint to fetch a list of organizations your keys have access to and match them to the records in your own system.
Test and production environments is the same infrastructure, thus the URLs will always be the same both when you are developing as well as running in production.
Make sure to use e-mail addresses and phone numbers which is used by someone on your team when you are developing. We will actually send the text messages while you are working!
When setting up your development account, we specifically set the account as test mode and it will not process any real payments. For the different payment methods, we mock them with fake integrations so you can test the payment flow. For special cases we can set up specific PSPs on their development/test infrastructure, although test keys will then be required in the setup.
When you are ready to go live, we will generate new production keys.
The API is designed to be backwards compatible with previous versions. If a new version of the API is released, the previous version will still be available at the same URL path.
However, changes might still be made to the API without a new version being released. For example, new fields might be added to a response, or new values might be added to an enum. Thus, care needs to be taken when integrating to ensure that your integration is resilient to these changes.
Whenever a new field is added, this will be marked with a date in the documentation, clearly stating when the field was added.
You will see a profileId field in the Payment model. This is the profile that the payment is being made for. This is a field that can help you set different branding, payment methods, and more for different customers or groups of customers.
A common use case for different profiles, is to have seperate communication for car sales and part sales, or if there's a special marketing campaign. It's also normal to have different payment methods for different profiles, as you would not buy a car with a credit card, but rather use a bank transfer for this.
For bigger more complex integrations, we highly recommend to make it as flexible and easy as possible to adjust the profileId based on what kind of payment it is. Please contact us if you have any questions or need help with this.
If the merchant do not require different profiles (almost all do), you can simply ignore this field, or use the simplified department field instead. For backwards compatibility, none of these fields is required, but we highly recommend to use them.
Manage Payment Profiles
Find the needed profileId for different profiles manually in the Spense Portal.
Use the API to get Payment Profiles
You can use the endpoint for fetching a list of organizations you have access to, for dynamically retrieving a list of payment profiles.
The API is has no hard rate limits, but we do reserve the right to rate limit any requests that we deem to be hurt the overall stability until we have added necessary measures to ensure stability. If you need to make a large number of requests (managing >10.000 new payments per day), please contact us to discuss your requirements.
We log metric related usage of the API, and may contact you if we notice any unusual usage patterns.
The API supports multiple languages. You can specify the language that you want to use by setting the Accept-Language header in your request. For example, to get the API to return responses in Norwegian, you would set the Accept-Language header to no. If you don't specify the Accept-Language header, the API will return responses in English.
This is useful if you want to display the API responses to your users, and want to display the responses in their language.
When making requests to the API, you should set the User-Agent header to identify your integration. This is useful for us to be able to identify your integration if you contact us for support, and to help us understand how the API is being used.
We actively monitor payments and look for issues, and this will help us greatly to early identify any issues with your integration.
Example of a User-Agent header:
User-Agent: MyIntegration/1.0A lot has happened with the Spense platform since inception, among others - a complete rewrite into a different programming language. But even still, in order to support integrations that was made for the initial versions of the platform, we are maintaining the old original APIs still.
Current status:
- Creating and managing payments are still currently using the old original API spec. We will eventually completely migrate to a v2 of this.
- If you made your integration before February 2024, you are probably authenticating in a different way than described in this documentation. We highly recommend that you migrate / change to the way of authenticating as described on this site. Your API keys remain the same.
Even though we from time to time deprecate APIs in favor of newer versions or no longer needed functionality, we recognize that it is not easy to migrate to newer versions for all customers. Due do this we will do our best to support deprecated APIs as long as there is traffic. However, we cannot guarantee the best quality in these cases.