Expense Management System

OpenCard is a great platform to improve the user experience of an Expense Management System (EMS). With OpenCard an EMS can receive information digitally such as receipts, credit card transactions, environmental impact information and all information is sent in real time.

To make your integration as seamless as possible the below information helps you understand the basic principals of OpenCard.

Onboarding

Onboarding includes both onboarding of clients as well as cardholders. The onboarding process is handled by OpenCard to make it as easy as possible for you as an EMS.
We recommend that you integrate your clients onboarding to OpenCard using our API following the onboarding sequence diagram below.

Model schema

Below is a simplified model schema of the most important models to help you develop against the OpenCard API. You will find the below resources, and much more, in the API Reference.

Legal framework

When integrating OpenCard in your EMS you will outsource the heavy lifting of the legal aspects to OpenCard. TPA, Transaction Processing Agreement, will be sent to the client to ensure that you as an EMS get the approval by the authorised signatories at the client to receive their transactions. This has historically been a time consuming and non user friendly experience.
PDPC, Personal Data Processing Consent, ensures that you as an EMS follows the EU's GDPR regulations when dealing with personal information.
All legal processes are of course 100% digital and secure using 2 way authorisation.
You provide the email address - we collect the consent.

Concept of Organizations

An organization in OpenCard is a way of defining your integration. In most cases an organization represents one client in your EMS, but there may be situations when you want to split your clients into two or more organizations in OpenCard. In order to explain the concept of an organization we start by explaining the components that define an organization.

Issuer tab
The issuer tab contains the Transaction Processing Agreement (TPA) and the card type selection. With this information you define the information you want to collect in your organization - eg. for client X (TPA X) you may want to include only the corporate cards, even if client X also has got private cards.

📘

Card types

It is important that you verify with your client what card types that should be included. It is common that a client has got multiple card types within their company.

Connection tab
In the connection tab you setup the webhook enpoint and the security schema. Eg. for client X you want the webhook events to be sent to your endpoint https://yourendpoint.com/clientx with basic auth.

Webhook tab
In the webhook tab you define which information you would like to subscribe on.

Cardholders tab
In the cardholders tab you define for whom you want the information to be sent - eg. at client X there might be 10 cardholders, but you only want the transactions and receipts for 5 out of 10 cardholders. You then create only these 5 cardholders

Using the components of an organization defined above, it is possible to create multiple organizations for client X in order to exclude certain users' corporate cards but not others as example.

Subscribing on Transactions

OpenCard supports transactions in 4 different states - you can receive the transactions on authorization (real time), clearing, invoiced and when a transaction gets deleted. As an EMS it is important that you always integrate cleared transactions to make sure that your clients receive the correct information for accounting purposes. For the best user experience possible, we recommend that you integrate 3 states; authorized, deleted and cleared.

Authorized transactions
The information is sent as soon as the purchase is carried out. This is a great way for your clients to be able to start working with the transaction directly (adding a photo receipt, setting up accounting information etc.). Please be aware that an authorized transaction may be changed or deleted at a later stage.

Deleted transactions
An authorized transaction may be deleted. The actual information of the deleted transaction is irrelevant, the event is designed to inform you to delete an authorized transaction in your system.

Cleared transactions
The cleared transaction is received 3-5 days after the purchase is carried out. The transaction has been cleared and the information of a cleared transaction will not be changed.

📘

Always include the cleared state

It is important that you always integrate cleared transactions to make sure that your clients receive the correct information for accounting purposes.

Invoiced transactions
The invoiced event occurs when a transaction has been invoiced. The information is the same as in the cleared transaction but with the addition of an included invoice number.

OpenCard recommends that you implement the transaction states in the following way:

• card.transaction.authorized, card.transaction.cleared and card.transaction.invoice creates a new transaction if the transaction id doesn't exist in your system.
• card.transaction.cleared and card.transaction.invoice updates an existing transaction if the transaction id already exists in your system.
• card.transaction.deleted deletes an existing transaction.

Current Card Issuer Integration

When integrating OpenCard for a client you may also be replacing an existing integration of transactions. This task includes managing potential double or missing transactions. It is your responsibility as an EMS to cancel the old flow of transactions from the card issuer. See below for specifik procedures for relevant issuer.

One way of handling this would be to:

• Stop the existing integration and start using the OpenCard integration per card holder when you receive the card_holder.identified event.
• When a card holder identifies in OpenCard you will receive all transactions since the latest credit card invoice. In order not to store duplicate you can use the card_issuer_reference attribute on the card.transaction.cleared event to identify if you have already stored the transaction via you existing integration.

First Card
Any refunds of charges for active services will be from the time of cancelation.