This guide walks the whole journey for a program that issues cards to its end users — from creating the user to a funded, ordered card. It spans three surfaces, so it’s easy to lose the thread; the diagram below shows who calls what. The flow has two variants, chosen by the prepaidCardCustomer flag when you create the identity:
Managed (prepaidCardCustomer: true)Default (prepaidCardCustomer: false)
Use caseProgram funds the card on the user’s behalfUser funds their own card via IBAN
FundingProgram master account via Load / UnloadUser’s assigned IBAN

​
Who calls what

​
Step 1 — Create the user

Provision the identity and its application with one call to POST /identity. prepaidCardCustomer here selects the funding model for the rest of the flow. 
POST https://api-control.next.orenda.finance/identity
Authorization: Bearer <access token>

{
  "email": "jane@example.com",
  "password": "YourPassword123!",
  "firstName": "Jane",
  "lastName": "Doe",
  "phone": "+31612345678",
  "prepaidCardCustomer": true,
  "dateOfBirth": "1990-01-01",
  "address": {
    "country": "NLD", "postCode": "1000AA", "province": "Noord Holland",
    "street": "Hoofdstraat", "town": "Amsterdam"
  }
}
You get back an applicationId. The full field reference (including which fields each variant requires) is on the Provision an identity page.

​
Step 2 — The user onboards (Customer API)

Everything from here until the card is the user acting with their own token on the Customer API. Hand the user their credentials; they sign in (and set up 2FA/passkey on first login), then move through onboarding:
  1. Accept legal agreements — POST /v1/applications/{applicationId}/agreements/legal/accept
  2. KYC — fetch the schema (GET /v1/applications/{applicationId}/kyc/schema) and submit answers (POST /v1/applications/{applicationId}/kyc)
  3. Identity verification (Sumsub) — get a token (GET /v1/applications/{applicationId}/webtoken/sumsub) and run the SDK
  4. Poll GET /v1/applications until onboarding completes
The full step-by-step for the user’s side — with request/response detail and the status model — lives on the Customer API docs: Issuing a card, end-to-end.
You don’t need to poll yourself: your program receives a webhook when the application is approved.

​
Step 3 — Order the card

Once approved, the application carries the customerId, and the user’s primary account is created automatically (read its accountId). Order the card: 
POST /v1/customers/{customerId}/accounts/{accountId}/cards
The user can order their own card on the Customer API, or you can order it on the Management API (POST …/cards/v2 with the right card claims) — see Card operations.

​
Step 4 — Fund the card

Load funds onto the card from the program master account:
POST /v1/customers/{customerId}/accounts/{accountId}/cards/{cardId}/balance

{ "amount": 100.00, "action": "LOAD" }
Use "action": "UNLOAD" to pull funds back to the master account.

Provision an identity

Create an identity and its application with POST /identity.

Card operations

Issue, status, limits, Load/Unload.

User-side walkthrough

The Customer API steps in full.

Webhooks

Get notified when the application is approved.