This is the build order for a user your program invited on the Management API. Every call here uses the user’s bearer token. Phases 1–3 are strictly sequential; cards and beneficiaries are independent of each other: build either, both, or neither, in any order. Payments need a saved beneficiary.
The application already exists. The invite creates the user and their application. Unlike the self-serve flow, you do not call POST /v2/applications: the user signs in to an application that’s already waiting for them.
1

Authentication

The user signs in with their email and the temporary password from the invite email. Login returns NEW_PASSWORD_REQUIRED, so they change the temporary password, then complete security setup (passkey or 2FA). There is no sign-up call. See Authentication overview for how challenges and tokens work. Send the resulting access_token as Authorization: Bearer <access_token> on everything below.
2

Onboarding

Poll GET /v2/applications and render the screen for each currentStep: legal agreements, KYC, identity verification. See Onboarding overview for the full state machine. This ends when currentStep is COMPLETED: the applicant is approved, becomes a customer, and gets a primary account created for them automatically.
3

Accounts

Approval creates the customer’s primary account automatically. You don’t call anything to create it. List accounts to read the accountId that the cards, payments, and beneficiaries endpoints need. See Accounts overview.How the account is funded depends on how the program invited the user. A managed (prepaid-card) invite means the program loads funds from its master account; nothing for your app to do. A default invite means the account has an assigned IBAN that the user funds by transferring to it. The program-side detail is on the Management docs.
4

Cards

Optional. If program capabilities say cards are on, order a card against the account. This doesn’t depend on beneficiaries, so do it in either order. Card spend shows up under transactions, not payments. See Cards overview.
5

Beneficiaries

Needed before payments. Every payment targets a saved beneficiary, so save the payee first, with an optional Verification of Payee check. See Beneficiaries overview.
6

Payments

Move money: domestic, international, scheduled, or batch. See Payments overview.
7

Transactions & statements

Show history and generate statements once there’s money moving. See Transactions overview.

​
If the user holds a card on a corporate’s account

A program can invite a user as a cardholder on a corporate: someone who holds a card on the corporate’s account but has no account of their own. The role they are invited under is EMPLOYEE, or one the program defines for its own cardholders, for example CONSUMER_CARDHOLDER. The order above still applies, with these differences; none of them needs a code path of its own:
  • Authentication. On a program that uses a client reference, the cardholder signs in through the program’s own identity provider, so there is no temporary password.
  • Onboarding. The program submits the cardholder’s KYC on its side. By the time they sign in, GET /v2/applications normally already reports currentStep: "COMPLETED", and its customerId is the corporate’s, exactly as for a corporate manager. Use that customerId in every path as you already do. The one onboarding screen they still see is legal acceptance, at first sign-in. currentStep doesn’t show it (it stays COMPLETED), so check application.legalAccepted and show legal acceptance while it is false.
  • Accounts. No account is created for them. The accounts list returns the corporate account(s) they were granted (one, or a subset of the corporate’s) with the corporate’s balance. Naming any other account of the corporate in a path returns 403; as a list filter it simply returns nothing.
  • Cards. The list returns only the card(s) ordered for this cardholder. Any card route called with another cardholder’s cardId is refused: 422 CARD_ACCESS_NOT_PERMITTED when that card sits on a granted account, 403 when it doesn’t.
  • Transactions. The full history of the granted account(s), including other cardholders’ spend on it. The account is shared.
  • Everything else is decided by the permissions on the role the program invited them under. A route the role does not include returns 403, so treat a 403 as “not available to this user”, not as an error to retry.