Managing Your Program

There are a few important concepts for you to know about as you build and manage your card program with Lithic's API:

• Program: When first getting started with Lithic's API, you will be provisioned with an API key, which you will use to interact with the API and build out your program. A program is a portfolio of account holders, accounts and cards that you create, each with their own funding sources and transactions. For Enterprise users, there may be certain configurations established during your setup that will apply across your program - for example, a single funding source for your cards, ability to use a "BYO" KYC or KYB option to create an account holder, etc.

• Default Account: When an API key is first provisioned and a program is set up, all activity (e.g., creating cards) will automatically take place within your default account. If you create additional account holders (and associated accounts), you can begin designating which other account an action should be taken on behalf of. For users who do not create additional account holders, all cards and transactions under their program are under the default account.

• Account Holders and Accounts:

  • An account holder represents the entity (either an individual or business) to whom a card is being issued, and the account holder object contains details for the entity itself such as contact information. The account, on the other hand, represents a set of configurations that impact whether transactions on cards belonging to the account are successful or not (e.g., transaction limits on the account).
  • Account holders and accounts have a 1:1 relationship. Any successful creation of an account holder object will automatically generate a corresponding account object. An account cannot be created by itself -- it can only be created by first creating an account holder.
  • An account holder is identified in the API with an account_holder_token and an account is identified with an account_token. After your first account holder (and account) is enrolled in the production environment, most subsequent API calls will require either an account_holder_token or account_token indicating which end-user this API request is on behalf of.
  • As an example, let's say a neobank program owner is looking to issue cards to a new individual end-user. They would first create an account holder object by passing in all of the required PII fields, and upon successfully doing so, will have also created an associated account object. The account holder object associated with that individual will contain important detail on the individual (e.g., phone number or email used for two-factor authentication for digital wallets) while the account object will contain configurations that impact transactions, such as the account state or an address used for AVS checks during a transaction.

• Cards: Cards created via the Lithic API can come in different forms - virtual or physical, digital wallet-enabled or not, PIN-enabled or not, etc. Since the Account object contains the configurations that determine the success of transactions, all cards created will either be associated with the default account or with an individual account that the program owner created.