Skip to main content
This section is for Expense Management Systems (EMS) — the apps that show employees and finance teams their card spend. OpenCard sits between card issuers and you. Issuers send card and transaction data to OpenCard. You receive it as webhooks, enriched with digital receipts, VAT, line items, and more when available. Your job has two halves. Both matter — and both should live in your product, not only in OpenCard’s UI.

​
What you integrate

We recommend you build the integration end to end. OpenCard’s application and optional plugins exist as shortcuts — the durable path is your own API integration.

​
1. Receive data — webhooks first

Before a single client is live, decide where OpenCard should send events and which events you want.
  1. Stand up an HTTPS endpoint that accepts POSTs from OpenCard
  2. Choose a security scheme (basic, oauth, custom, or none) so only OpenCard can call you
  3. Complete the webhook challenge (HMAC handshake) so OpenCard knows you own the URL
  4. Subscribe to the events you need — transactions, TPA signed, card holder identified, receipts, TrueVAT, line items, …
Every organization has its own webhook config. Transaction data arrives here — there is no “list all transactions” pull API for day-to-day spend.

​
2. Onboard customers — in your product

Once webhooks work, wire client onboarding into your EMS. That is the path we want partners on.

​
Marketplace — payment products

Show the cards you sell. Clients pick a payment product before legal setup. → Payment product setup

​
TPA — company authorization

Create the Transaction Processing Authorization, look up who may sign via public records, collect signatory emails, and let OpenCard run eID signing. You get tpa.signed when it is done. → Customer onboarding · TPA flow · eID signing

​
Card holders — keep people in sync

Create and maintain card holders for each employee whose spend should appear. Email + PDPC, or instant match with identity_id when the person is already known to OpenCard. → Card holders

​
The model (why the entities exist)

You will create billing, organization, TPA, and card holder records while onboarding. They are not abstract — each maps to invoice roll-up, a client company, legal permission, or an employee. Deep hierarchy context → How OpenCard works

​
Map of this section

Customer onboarding

End-to-end client setup — marketplace, TPA, public records, card holders, then live webhooks.

Webhooks

Endpoint, security scheme, challenge, and every event you can subscribe to.

Model

Billing, organization, TPA, and card holder — the objects your API calls create.

EMS API

Application API reference — payment products, public records, TPAs, orgs, webhooks.
Also useful: Current card issuer integration if the client already has an issuer feed, Error handling, and Plugins if you temporarily use OpenCard-hosted UI widgets.