Issuing Cards

Card issuance is performed through the Card API after the required program records have been created.

The exact issuance flow depends on the program model, but card creation always sits on top of an existing owner record and account structure.

Card creation prerequisites

Before a card can be created, the required owner and account records must already exist in FINCI.

In the default models described in this portal:

• corporate programs create cards against the relevant corporate, account, and employee structure
• consumer programs create cards against the relevant person and account structure

This guide focuses on the card-level considerations rather than the full record-creation flow.

Card creation request

A card creation request is built around three parts:

• the owner reference
• the card product and cardholder details
• the issuance and delivery settings

In practice, the API schema includes fields such as:

• the relevant owner identifier, depending on the program type
• product_id, provided by FINCI as part of the agreed product setup
• embossing_name
• expiration_date
• token_status
• token_stage
• delivery_address
• express_delivery

In the current API schema, delivery fields are required on all card-creation requests, including digital-first issuance.

For consumer flows, some endpoint and field names may still use client terminology even where the business object is described in these guides as a person.

Use the API Reference for the exact required fields and payload format.

Default issuance profile

For Commercial Cards via API, the default issuance profile is digital-first.

In the current API schema, card creation supports:

• token_status: new or active
• token_stage: digital or plastic_not_delivered

The normal commercial flow is:

• token_status = active
• token_stage = digital

That means the card is created in digital stage and active status. The active status, not the stage, is what makes the card usable immediately for transactions unless a different issuance setup is agreed for the program.

Where a card is created with token_status = new, the card may exist but remain unusable for authorization until activation is completed.

Issuance models

The same card creation structure can support different issuance models, depending on the agreed product setup and customer journey.

• digital-first issuance The card is created in digital stage, typically with an active status for immediate use.
• physical issuance pending delivery The card is created with physical fulfillment in progress, while the stage reflects that the plastic card has not yet been delivered.
• inactive issuance pending activation The card is created but remains in new status until the required activation step or agreed program condition is completed.

The combination of product_id, token_status, token_stage, and delivery settings should reflect the intended issuance model for the program.

Sensitive card data handling

Any retrieval, storage, transmission, or display of card data must be governed by the applicable compliance model and internal security controls.

At a minimum:

• sensitive card data must not be written to application logs
• access must be restricted to the systems and operators that require it
• internal distribution of card data should be minimized
• decryption keys and related cryptographic material must be stored, managed, and used securely
• downstream handling must follow the agreed compliance and security requirements for the program

This guide does not define the permitted retrieval scope for sensitive card data. That scope must follow the API contract, the agreed product setup, and the applicable compliance obligations.