Individual Accounts
Partner-owned individual accounts represent end-customers onboarded by a single partner. Each onboarding record is the canonical customer record for a person — it bundles the client profile, the debit account, the addresses, and risk/compliance flags into one document owned by exactly one Partner.
The data of an individual
An onboarding record groups five categories of data:
| Field group | Examples |
|---|---|
| Identity | firstName, lastName, email, phoneNumber, legalId, applicationId |
| Address | address.{street, buildingNumber, apartmentNumber, city, stateProvince, zipCode, country} (both residential and delivery) |
| Accounts | The settlement account the individual links to, with IBAN and customerType |
| Compliance | applicationStatus, applicationDate, riskStatus, riskLevel, isPep, operationStatus, dashboardStatus |
The clientCode (e.g. PNVS-0001) is the immutable identifier you use across every other endpoint — it is the canonical handle for the individual.
Lifecycle states
Each IndividualOnboarding progresses through three stages. The state is split across two flags:
| Stage | applicationStatus | operationStatus | Meaning |
|---|---|---|---|
| Draft | PENDING / SUBMITTED | Pending | Profile created, but the customer hasn't completed KYC / onboarding. |
| Active | APPROVED | Active | Customer is fully onboarded; cards can be issued against them. |
| Inactive | REJECTED | Inactive | Onboarding rejected (KYC failure, sanctions hit, etc.) or the customer churned. No new cards can be issued. |
The admin-side state uses a parallel dashboardStatus flag (ACTIVE / INACTIVE / PENDING / REJECTED / APPROVED) that PayNovus uses internally; it may surface in the response payload but is not the source of truth for the partner.
Risk & compliance
Every individual carries risk metadata:
riskLevel—LOW/MEDIUM/HIGH/VERY HIGH(set during onboarding).riskStatus— current risk state.isPep— boolean flag for politically-exposed persons.hasAgreedToTerms,hasAgreedToTariffs,hasCompletedBiometrics— onboarding checkpoints.
High-risk individuals (HIGH / VERY HIGH) and isPep: true customers are blocked from card issuance by the partner-side validation.
Tenant scoping
Every route under /individual/accounts/:id/* is automatically scoped to your partner. If you pass an :id that does not belong to your partner, the endpoint returns 404 Not Found with no further detail — the response is identical whether the record does not exist or belongs to another partner, so a caller cannot probe your partner's records.
Lifecycle
| State | Trigger |
|---|---|
| Draft | Account created via POST /individual/accounts (not yet active) |
| Active | Cards issued via /cards/virtual or /cards/physical |
| Closed | Account terminated by PayNovus (not currently exposed on the partner surface) |
The Partner API does not yet expose a profile-update endpoint for partner-owned individuals. Profile changes must currently be coordinated through PayNovus support. Reach out via your usual channel to request changes.
What you can do
The Individual Accounts area covers:
- Account onboarding — create a new individual account owned by your partner.
- Account lookup — list and fetch accounts by id.
- Card issuance — issue a virtual or physical card against an account.
- Account-scoped reads — audit logs, card status history, and transactions for an account.
For the exact endpoint shapes, parameters, and the Try it widget, see the List of endpoints → page.
A B2B cardholder is an IndividualOnboarding linked to one of your tenants (b2bClient). The cardholder lifecycle is the same — same onboarding schema, same card APIs — but the routes are tenant-scoped:
POST /business/accounts/{b2bAccountId}/cardholders(PayNovus approval, returns202 PENDING)GET /business/cardholders/{id}//cards//ibans/for-issuingPOST /business/cardholders/{id}/cards/virtual//physical
See Business Accounts (B2B) → for the full tenant and cardholder flow.