Cardholder Verification

Cardholder Verification confirms that a card belongs to its declared holder — entirely back-end, with no visual capture step.

What it does

Confirms that the CPF and the card presented belong to the same person — a card-not-present ownership check. It reuses a previously validated process (referenced by its id, referenceProcessId) together with the person's CPF and card data (bin/last4) to answer the check directly, without running a new capture step.

Not the same as Card Not Present Verification

This capability is a different integration surface from the Card Not Present Verification product.

Inputs

• The document type, sent via subject.duiType (currently DUI_TYPE_BR_CPF only), and the CPF value via subject.code.
• card: bin (the card's first 6 or 8 digits) and last4 (the last 4 digits), name is optional.
• referenceProcessId — the id of the previously validated process being reused, where this person's identity was already confirmed (Identity Verification or Liveness). This capability's current version is reuse-based: without this field, the gate is never triggered and the response defaults to the standard unsure result — the request itself never fails.
• Triggered via POST /processes/v1 with a Recipe (API key) that includes Cardholder Verification. It is enabled per API key through the Recipe (or capabilities_enabled), not through the flow field.

Possible responses

Response	Meaning
approved	The CPF and the card belong to the same person.
unsure	Either there's no valid process to reuse, or the verification itself was inconclusive.
(omitted)	The verification didn't conclude within the synchronous call. The cardholderVerification field is absent from the Get Process response, and status reflects the process is still processing.

Availability

Surface	Supported
SDK (Android, iOS, Flutter)	❌ Backend-only capability, no capture step
Web (iFrame, Redirect)	❌ Backend-only capability, no capture step
API (headless, no SDK)	✅

Valid combinations

Cardholder Verification isn't part of the pre-composed flow catalog — it's enabled directly on the API key's Recipe (or capabilities_enabled, for non-IDCloud keys), independently of the flows in Available flows.

Use cases that use this capability

There are no published use cases referencing this capability yet.