The application already exists. When the program calls
POST /identity on the Control
API, it creates the user and their application. So unlike self-serve onboarding, you do
not call POST /v1/applications here — the user signs in to an application that’s
already waiting for them.The flow
Step 1 — Sign in
The user signs in with the email and password the program set when it created them. On first login they’re prompted to change the password and set up 2FA or a passkey. See Authentication. Use the resulting token on every call below.Step 2 — Accept legal agreements
When the application’scurrentStep is LEGAL_AGREEMENTS, accept the program’s terms:
Step 3 — Complete KYC
Fetch the KYC form schema, render it, and submit the answers:Step 4 — Identity verification (Sumsub)
Get a Sumsub web token and pass it to the Sumsub Web/Mobile SDK for document upload and liveness:Step 5 — Wait for approval
PollGET /v1/applications and render the screen for each
currentStep. When currentStep is null, onboarding is done. (Your program also gets a
webhook on approval.) The full status model is in the
Onboarding overview.
Step 6 — Read customerId and accountId
The approved application carries thecustomerId, and the user’s primary account is
created automatically. Read it to get the accountId:
Step 7 — Order the card
Funding
How the card is funded depends on how the program created the user (prepaidCardCustomer):
- Managed — the program loads funds from its master account; nothing for your app to do.
- Default — the user’s account has an assigned IBAN; the user funds the card by transferring to it.