Core Data Model

The integration relies on a small set of records that define program ownership, card issuance, and transaction activity.

Program and ownership records

Corporate

The corporate record is the top-level business entity for corporate programs.

Accounts and cards are typically created under this structure.

Account

The account record represents the financial account used for card issuance and transaction activity.

Internal ledger mapping to FINCI account records should be explicit and consistent.

Cardholder

The cardholder record linked to a card depends on the program model:

• employee in a corporate program
• person in a consumer program

This record identifies who the card is issued to within the agreed program model.

In some API endpoints, the consumer-side record may still be referred to as client. In these guides, person is the preferred business term.

Card record

Card

The card record is the payment instrument used for transactions.

A card is created against an existing owner record and account structure.

A card has both:

• a status for operational usability
• a stage for physical fulfillment state

Those two concepts should not be collapsed into one internal field.

Transaction records

Authorization

The authorization record represents a real-time authorization message, including transaction authorization requests and authorization reversals depending on the authorization type.

This is an operational decision point rather than a final financial posting.

Transaction

The transaction record represents the financial event that results from authorization and later clearing activity.

The integration model should be able to connect:

• original authorization
• later clearing
• possible reversal
• possible return

Relationship model

The following conceptual model shows how the main records connect across program setup, card issuance, and transaction processing.

Use this diagram as a relationship map rather than as a strict field-by-field contract. The API Reference remains the source of truth for exact schemas and payload formats.

At a high level:

• corporate and account records define program ownership and funding structure
• employee or person records define the cardholder
• product and card records define the issuance setup and payment instrument
• authorization and transaction records represent the transaction lifecycle
• delivery details are part of the card-creation payload and become operationally relevant for physical fulfillment

Default setup order

The setup sequence depends on the target program model.

• for corporate programs: corporate -> account -> employee -> card
• for consumer programs: person -> account -> card

Use this as the default record-creation order unless the agreed program setup defines a different flow.