> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synctera.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Card-Account Relationship and Funding Hierarchies

> Every card is linked to an account, and that account is what the card spends against. The account type you choose follows from the card type, and the funding structure follows from your use case.

This guide covers three decisions that shape how money reaches your cards: which account type backs each card type, whether cards draw on their funding account directly or through a hierarchy, and how many cards an account can hold.

## Account types

Synctera uses different account types for different card types. In practice you build a separate [account template](/v2/docs/create-accounts-guide) for each card type you offer, and create accounts from that template.

| Card product                     | Account type                                               | Account guide                                                             |
| -------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------- |
| Debit card                       | `CHECKING`                                                 | [Checking and Savings Accounts](/v2/docs/checking-savings-accounts-guide) |
| Reloadable prepaid card          | `CHECKING`                                                 | [Checking and Savings Accounts](/v2/docs/checking-savings-accounts-guide) |
| Non-reloadable prepaid card      | `PREPAID`                                                  | [Create Accounts](/v2/docs/create-accounts-guide)                         |
| Secured Smart Card (charge card) | `CHARGE_SECURED` + a deposit account as security           | [Secured Charge Accounts](/v2/docs/secured-sc-accounts-guide)             |
| Unsecured Charge Card            | `CHARGE_UNSECURED`                                         | [Unsecured Charge Accounts](/v2/docs/unsecured-charge-accounts-guide)     |
| Revolving credit card            | `REVOLVING_CREDIT_SECURED` or `REVOLVING_CREDIT_UNSECURED` | [Line of Credit Accounts](/v2/docs/line-of-credit-accounts-guide)         |

<Note>
  A card account must have cards enabled. Set `is_card_enabled` to `true` on the account template, or on the account itself. Accounts that only fund other accounts — pool accounts and funding parents — normally have cards disabled and P2P enabled instead.
</Note>

## Funding relationships

How a card is funded depends on whether it spends directly from the account that holds the money, or from an account that is topped up from elsewhere.

### Direct funding

The card is linked directly to the funding account. The balance the cardholder can spend is the balance on that account.

```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart LR
  A["Account<br/>(CHECKING)"] --> C["Card"]
```

Common use cases:

* Consumer debit programs
* Consumer prepaid programs
* Consumer credit programs — these technically fall under direct funding, although the available balance or credit is backed by a linked deposit account or line of credit

### Just-in-time funding

The card is linked to an account that is itself funded by another account, either in real time or through just-in-time (JIT) funding. There can be multiple levels of funding accounts above the card's account.

```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart LR
  A["Funding account<br/>(pool)"] --> B["Card account"] --> C["Card"]
```

Common use cases:

* Commercial and small business debit and prepaid programs
* Commercial credit programs

JIT funding is built with balance floors and ceilings on the card's account, which trigger a transfer from the parent account when the balance falls below the floor. See [Balance Floor and Ceiling and Linked Accounts](/v2/docs/balance-floor-ceiling) for the mechanics, and [Business Expense Cards](/v2/docs/business-card) for a worked example that combines a pool account, per-employee accounts, and spend controls.

## Number of cards per account

The maximum number of cards a person can hold on a card product is configured on the card product itself, through `card_limit`. This limit is not applied to business cards.

* **Consumer programs** are limited to one active (non-terminated) physical card and a small number of active virtual cards per account. The exact virtual card limit is set on your card product — check `card_limit` on the product via [List Card Products](/v2/reference/listcardproducts).
* **Commercial and business programs** have no limit on the number of active physical and virtual cards per active account.

<Info>
  Terminated cards do not count toward the limit. If a customer has reached their limit, terminate an unused card before issuing a new one, or reissue the existing card rather than issuing an additional one.
</Info>

## Assigning a card to a customer later

A card can be issued against a business without naming a cardholder. Pass `business_id` without `customer_id` at issuance, and the card is created but cannot be activated or used for spend until a person is assigned to it with [Update Card](/v2/reference/updatecard).

This is how bulk programs work: cards are manufactured and shipped to the business in bulk, then assigned to individual employees on site. See [Bulk Card Orders](/v2/docs/bulk-card-orders).