> ## 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.

# Design Your Card Program

> Before you issue a card, you decide what kind of card program you are building. Brand, category, type, and format together determine what your cards can do, what they cost, and who they suit.

What type of card program you want to offer to your customers depends on your business use case and your goals. The Synctera platform offers a variety of card brands, categories, types, and formats for you to choose from. These are described below.

This guide covers the choices that define a card program. Your Synctera Implementation & Onboarding manager configures the program based on these choices and your sponsor bank agreement, so work through them before you start building.

## Card brands

Synctera issues cards on two networks:

| Brand      | `card_brand` |
| ---------- | ------------ |
| Mastercard | `MASTERCARD` |
| Visa       | `VISA`       |

The brand is fixed at the card product level and cannot be changed on an issued card.

## Card categories

A card product is either consumer or commercial:

| Category   | `card_category` | Use it for                                                                                         |
| ---------- | --------------- | -------------------------------------------------------------------------------------------------- |
| Consumer   | `CONSUMER`      | Cards issued to individual people for personal spending                                            |
| Commercial | `COMMERCIAL`    | Cards issued to businesses — including small business programs — for employee and company spending |

The category affects interchange rates, and the BIN your cards are issued on. See [Card-Account Relationship and Funding Hierarchies](/v2/docs/card-accounts-funding).

## Card types and use cases

The `card_type` on a card product is `DEBIT`, `CREDIT`, or `PREPAID`. Within those three, Synctera supports several distinct products:

<AccordionGroup>
  <Accordion title="Debit">
    Pulls funds directly from the cardholder's linked deposit account at the time of purchase.

    * **Primary use case:** Everyday spending and cash management
    * **Best for:** Consumers, neobanks, payroll and benefits programs

    **How to build:** [Debit Card](/v2/docs/build-debit-card)
  </Accordion>

  <Accordion title="Prepaid">
    Spends from a pre-loaded balance. Prepaid cards can be reloadable or non-reloadable.

    * **Primary use case:** Controlled, limited, or purpose-specific spending
    * **Best for:** Gift cards, allowances, stipends, serving the underbanked

    Non-reloadable prepaid cards are the usual choice for gift card programs, where the card is bought with a fixed value and discarded when spent. Reloadable prepaid cards behave much more like debit cards and are typically funded on an ongoing basis.

    **How to build:** [Prepaid Card](/v2/docs/build-prepaid-card)
  </Accordion>

  <Accordion title="Secured Smart Card (charge card)">
    Requires a cash deposit as collateral and must be paid in full each billing cycle. The spending limit is tied to the available balance in a linked deposit account.

    * **Primary use case:** Credit access with risk mitigation
    * **Best for:** Credit builders and new-to-credit users

    Because it runs on credit rails, a Smart Card generally earns higher interchange than a debit card, and payment history can be reported to the bureaus for credit building — without underwriting or a credit check.

    **How to build:** [Secured Smart Card](/v2/docs/build-smart-card)
  </Accordion>

  <Accordion title="Unsecured Charge Card">
    Offers a credit line with no collateral and requires full repayment each billing cycle.

    * **Primary use case:** Short-term liquidity and premium spending
    * **Best for:** Affluent consumers, travel and entertainment, business spend

    **How to build:** [Unsecured Charge Card](/v2/docs/build-charge-card)
  </Accordion>

  <Accordion title="Revolving Credit Card">
    Allows cardholders to carry a balance over time, paying interest on unpaid amounts.

    * **Primary use case:** Flexible financing over time
    * **Best for:** Consumers who need payment flexibility

    **How to build:** [Revolving Credit Card](/v2/docs/build-revolving-credit-card)
  </Accordion>

  <Accordion title="Fleet Card">
    Gives businesses that run vehicle fleets a way to manage fuel, maintenance, and repair expenses. Typically set up as a Secured Smart Card.

    * **Primary use case:** Vehicle-related expense management
    * **Best for:** Commercial fleets, logistics, and service companies

    Fleet programs frequently need control over the preauthorization hold that automated fuel dispensers place on a card. Card products expose `afd_preauth_limit` for this, which overrides the standard processor hold amount up to \$1,000.

    **How to build:** Link coming soon
  </Accordion>
</AccordionGroup>

<Note>
  Credit products require specific privileges on your organization. Contact your Synctera representative before you plan a credit, charge, or revolving program.
</Note>

## Card BINs

A Bank Identification Number (BIN) is the leading digits of the card PAN that identify the issuing bank, the network, and the product characteristics. Your BIN is assigned as part of your sponsor bank agreement and is tied to a brand, category, and type — a single BIN might be Mastercard, consumer, debit.

You do not choose a BIN per card. The card product is attached to a BIN or account range, and every card issued on that product inherits it. Two consequences matter in practice:

* **Changing brand, category, or type means a new BIN**, which means reissuing cards with a new PAN under `PRODUCT_CHANGE`.
* **Cross-border behavior is evaluated against the BIN country.** When `cross_border_enabled` is false on the card product, transactions are declined automatically whenever the merchant country differs from the BIN country. Cross-border transactions are disabled by default.

## Card formats

Every card is either physical or virtual, set by the `form` field:

<CardGroup cols={2}>
  <Card title="Physical" icon="credit-card">
    Tangible plastic or metal cards, manufactured by a card fulfillment provider and shipped to the cardholder.

    Supports card-present transactions such as in-store purchases and ATM withdrawals, as well as card-not-present transactions online. Cards can be added to a digital wallet.
  </Card>

  <Card title="Virtual" icon="mobile-screen">
    Generated immediately, with no manufacturing or shipping.

    Supports card-not-present transactions, and can be added to a digital wallet — which also makes them usable in-store through Apple Pay or Google Pay.
  </Card>
</CardGroup>

Physical cards are dual interface: the embedded chip supports both contact (dip or swipe) and contactless (tap, NFC) transactions. The `physical_card_format` on the card product records which interfaces a product supports.

### Our recommendation — virtual first

For any use case, Synctera recommends a virtual-first strategy:

* **Issue a virtual card during onboarding**, even when you also plan to issue a physical card. A virtual card eliminates the wait for plastic to arrive in the mail.
* **Let customers start spending immediately.** The earlier customers spend, the earlier you earn interchange, and the likelier they are to stay with you.
* **Push digital wallet enablement.** Adding a card to Apple Pay or Google Pay significantly improves security and strongly encourages top-of-wallet status, because contactless checkout is faster and drives higher, more frequent usage. See [Digital Wallets](/v2/docs/digital-wallets).

## Personalized and non-personalized cards

Most cards are personalized: the cardholder's name is printed on the card, set through `emboss_name` at issuance. The name is limited to 21 characters, and valid characters are `A-Z`, `a-z`, `0-9`, space, period, comma, forward slash, hyphen, ampersand, and apostrophe.

Non-personalized cards carry no cardholder name. They suit two main cases:

* **Gift cards** — non-reloadable prepaid cards that do not require a name or KYC. Card products can set `issue_without_kyc` to allow issuing on the product without KYC verification.
* **Bulk-shipped cards** — cards sent in bulk to a business and assigned to cardholders on site. See [Bulk Card Orders](/v2/docs/bulk-card-orders).

<Tip>
  For customers who have specified a chosen name, set `emboss_name` explicitly with their chosen and last name to override the default of first and last name.
</Tip>
