> ## Documentation Index > Fetch the complete documentation index at: https://next-developers.opencard.io/llms.txt > Use this file to discover all available pages before exploring further. # Overview > Full EMS customer onboarding — billing, TPA, organization, webhook, and card holders — the complete flow from client signup to live transactions. This is the **end-to-end path** for connecting one of your clients to OpenCard. Everything you need lives in the Application API — no embed plugin required. The guides below this page go deeper on TPA signing, eID, and card holders. *** ## Who does what | Actor | Role | | ------------- | ----------------------------------------------------------------------------------------------------- | | **Client** | Your end-customer company — signs the TPA; their employees sign PDPC | | **You (EMS)** | Orchestrate setup in your product — call OpenCard APIs, store `reference_id`s, show status in your UI | | **OpenCard** | Legal signing (eID), card issuer communication, webhooks with transactions and enrichment | You own the UX. OpenCard owns signing pages, identity verification, and data delivery. *** ## Big picture ```mermaid theme={null} sequenceDiagram participant Client as Client participant You as You (EMS) participant OC as OpenCard Note over Client,OC: Phase 1 — Client setup Client->>You: Choose card program You->>OC: GET account cardissuers Client->>You: Choose products + invoice details You->>OC: GET publicrecords (who may sign TPA) Client->>You: Confirm TPA signatories + emails You->>OC: Configure client (billing, TPA, org, webhook) OC->>Client: TPA signing email (eID) Client->>OC: Sign TPA OC->>You: tpa.signed webhook Note over Client,OC: Phase 2 — Cardholder setup Client->>You: Add employee You->>OC: Create Card holder OC->>Client: PDPC email (eID) — Path A Client->>OC: Sign PDPC OC->>You: card_holder.identified Note over Client,OC: Phase 3 — Live OC->>You: Transaction + receipt webhooks You->>Client: Show spend in your EMS UI ``` *** ## Phase 1 — Client setup This is what the **client** walks through in your product (same order as the optional [ocTPA plugin](/ems/plugins)). You collect choices in the UI, then create the OpenCard resources. ```mermaid theme={null} flowchart LR A[1. Card program] --> B[2. Products] B --> C[3. Invoice details] C --> D[4. Create TPA] D --> E[5. Configure client] ``` ### 1. Choose card program ``` GET /accounts/{accountId}/cardissuers ``` Show only issuers **already enabled** on your account. The client picks one → you store `card_issuer_id` for the TPA. Enabling new issuers on the account is one-time platform setup — not part of this per-client wizard. → [Quickstart](/getting-started/quickstart) ### 2. Choose products What OpenCard should deliver for this client. Stored as flags on the **billing** profile when you create it:
Field Meaning Typical UX
product\_transaction Real-time transaction states to your webhooks Usually always on
product\_digital\_receipt Digital receipts from the merchant network Optional toggle
product\_aland\_index Environmental impact estimates Optional toggle
Transactions are the core product. Receipts and environmental impact are enriched add-ons — same split the plugin uses (“Transaction information” vs “Enriched information”). → [Billing](/ems/model/billing) · [Receipts](/ems/receipts) · [Environmental impact](/ems/environmental-impact) ### 3. Invoice details (for your OpenCard bill) Collect how **you** (the EMS) want this client represented on the invoice OpenCard sends **you**: * Invoice email (`email_invoice`) * Your reference (`your_reference_invoice`) * Legal name / org number / address (often from public records) Organizations that share the same billing profile appear as **one line** on that invoice — not as separate invoices per organization. This is not the bank’s card invoice to the client. → [Billing](/ems/model/billing) ### 4. Create the TPA (company authorisation) A **TPA** (Transaction Processing Authorisation) is the legal agreement that this company allows card transaction data from the chosen card program to flow through OpenCard to **your EMS**. Look up who is allowed to sign: ``` GET /accounts/{accountId}/publicrecords?country=SE&organization_number=... ``` Use `signature_combinations` when present so the client picks a valid signing group. Collect **name + email** for each person who will sign (or allow manual entry when the registry has no combinations). You create the TPA and signatories in the next step. Full walkthrough → [TPA flow](/ems/tpa-flow) · [eID signing](/ems/eid-signing) ### 5. Configure the client When the client confirms steps 1–4, create the OpenCard resources (same payload shape the [ocTPA plugin](/ems/plugins) returns in `onDataSend`): ``` POST /accounts/{accountId}/billings ← invoice line + product flags POST /accounts/{accountId}/tpas ← company + card_issuer_id POST /accounts/{accountId}/tpas/{tpaId}/signatories ← emails → eID signing links POST /accounts/{accountId}/organizations ← runtime container POST /accounts/{accountId}/organizations/{id}/webhooks ← event delivery ``` OpenCard emails each TPA signatory. They sign with national **eID**. You wait for status — do not build your own signing UI. | Event / signal | Meaning | | -------------------- | ---------------------------------------- | | Signatory signs | Progress toward fully signed | | `tpa.signed` webhook | All required signatures done — PDF ready | | Status → `activated` | TPA confirmed — transactions can flow | **Organization body** — link the TPA and billing you created. `reference_id` is **your** internal client ID (returned on every webhook): ```json theme={null} { "reference_id": "client_acme_001", "tpa_id": 42, "billing_id": 1, "name": "Acme AB" } ``` Complete the [webhook challenge handshake](/ems/webhooks/setup#challenge-handshake) so `active=true` and events can be delivered. → [Billing](/ems/model/billing) · [Organization](/ems/model/organization) · [Webhook setup](/ems/webhooks/setup) · [TPA flow](/ems/tpa-flow) Client setup is complete when the TPA is signed (ideally activated), the organization exists with `billing_id` + `tpa_id`, and the webhook is active. *** ## Phase 2 — Cardholder setup Goal: each person whose card spend you want is identified in OpenCard. ``` POST /accounts/{accountId}/organizations/{organizationId}/cardholders ``` | Path | You send | User action | Transactions start | | ----------- | ------------- | ------------------- | ------------------------------ | | 🅰️ Email | `email` | Signs PDPC with eID | After `card_holder.identified` | | 🅱️ Instant | `identity_id` | None | Immediately | OpenCard handles PDPC email + eID. You handle status in your UI (`card_holder.identified`, `card_holder.signed.pdpc`). → [Card holder onboarding](/ems/card-holders) · [Model: Card holder](/ems/model/card-holder) · [eID signing](/ems/eid-signing) Cardholder is onboarded when you receive `card_holder.identified` — then expect transactions (including a retroactive batch). *** ## Phase 3 — Live Once card holders are identified and the TPA is activated: 1. Card issuer pushes transaction states to OpenCard 2. OpenCard POSTs to your organization webhook (`card.transaction.*`) 3. Enrichment may follow: `receipt.fetched`, true VAT, line items, environmental impact → [Transaction states](/ems/webhooks/transactions) · [Events](/ems/webhooks/events) · [Receipts](/ems/receipts) *** ## Ordered checklist Do this **per client** (after your account + OAuth client exist): | # | Step | API / action | Detail guide | | - | --------------------------------------- | -------------------------------------------------------------- | --------------------------------------------------------------- | | 0 | Enable card issuer(s) on account (once) | `GET /cardissuers` → `POST .../accounts/{id}/cardissuers/{id}` | [Quickstart](/getting-started/quickstart) | | 1 | Client picks card program | `GET .../accounts/{id}/cardissuers` | below | | 2 | Client picks products | Flags on billing create | [Billing](/ems/model/billing) | | 3 | Invoice email / reference | Part of billing create | [Billing](/ems/model/billing) | | 4 | Create TPA (who signs) | `GET` publicrecords — collect signatories | [TPA flow](/ems/tpa-flow) | | 5 | Configure client | `POST` billings, tpas, signatories, orgs, webhooks | [Billing](/ems/model/billing) · [Webhooks](/ems/webhooks/setup) | | 6 | Wait for eID + `tpa.signed` | Webhook / status | [eID signing](/ems/eid-signing) | | 7 | Create card holders | `POST` cardholders | [Card holders](/ems/card-holders) | | 8 | Wait for `card_holder.identified` | Webhook | [Card holders](/ems/card-holders) | | 9 | Handle transactions + enrichment | Webhooks | [Transactions](/ems/webhooks/transactions) | *** ## Build it yourself vs embed plugin | Approach | When | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **API only (this guide)** | Rebuild the same steps in your own UI — recommended for production | | **[ocTPA plugin](/ems/plugins)** | Ready-made wizard: issuer → products → invoice → signatories; **you still POST** billing / TPA / signatories from `onDataSend` | The plugin mirrors steps 1–4 in the UI and gives you billing / TPA / signatory data in `onDataSend`. Step 5 (organization + webhook) and card holders stay in your integration. *** ## Deep dives in this section | Page | What it covers | | ------------------------------------------- | ----------------------------------------------- | | [TPA flow](/ems/tpa-flow) | Create TPA, signatories, activation, signed PDF | | [eID signing](/ems/eid-signing) | Sign vs auth modes across Nordic countries | | [Card holder onboarding](/ems/card-holders) | Email vs `identity_id`, webhooks, updates | **Models** (what each entity is): [Billing](/ems/model/billing) · [Organization](/ems/model/organization) · [TPA](/ems/model/tpa) · [Card holder](/ems/model/card-holder)