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

# Debit Card

> A debit card spends directly from a customer's deposit account at the time of purchase. It is the simplest card program to run — no underwriting, no credit decision, no repayment.

A debit card is an access mechanism for money the customer already has. Each purchase draws against their deposit account balance, so there is no credit risk, no billing cycle, and no repayment to manage. That makes it the fastest card program to stand up and the usual starting point for consumer and neobank products.

## Overview

### Key Concepts

Three mechanisms determine how a debit program behaves day to day.

<AccordionGroup>
  <Accordion title="Funding and available balance">
    The card is linked to a deposit account, and that account's balance is the card's spending power. Synctera tracks two balances:

    * **`ACCOUNT_BALANCE`** — the posted balance: credits minus debits across all posted transactions.
    * **`AVAILABLE_BALANCE`** — what can actually be spent: the account balance minus any pending debits, including holds placed by card authorizations that have not yet cleared.

    Authorizations are evaluated against the available balance, which is why a customer who just made a purchase sees less spending power than their posted balance suggests.
  </Accordion>

  <Accordion title="Authorization and settlement">
    Card spend reaches you in two parts. At the moment of purchase the network sends a **funding request**, Synctera approves or declines it, and an approval places a hold against the available balance. You can also participate in the authorzation flow.

    Later the merchant submits the transaction for **clearing**, and the money actually moves. The cleared amount can differ from the authorized amount — a tip added after the card is swiped, or a fuel pump that authorizes a fixed amount and clears what was pumped. An authorization advice adjusts the hold in between; a reversal releases it entirely.

    ATM withdrawals and PIN debit purchases are **single-message**: authorized and cleared together, so funds move immediately.

    See [Card Transactions](/v2/docs/card-transactions).
  </Accordion>

  <Accordion title="PIN and card-present use">
    A debit card needs a PIN for ATM withdrawals and for point-of-sale transactions where the merchant requests one. This applies to virtual cards too — a merchant terminal can ask for a PIN when the card is used through a digital wallet, and a card with no PIN set cannot complete that purchase.
  </Accordion>
</AccordionGroup>

### How It Differs from Other Card Types

| | Debit | Prepaid | Credit and charge |
| - | - | - | - |
| Funds come from | The customer's deposit account | A pre-loaded balance | A credit line |
| When money leaves the customer | At clearing | At clearing | At repayment |
| Underwriting | None | None | Required |
| Interest | None on card spend | None | On carried balances (revolving only) |
| Account types | `CHECKING` | `CHECKING` or `PREPAID` | `CHARGE_*`, `CREDIT_CARD` |

See [Prepaid Card](/v2/docs/build-prepaid-card), [Secured Smart Card](/v2/docs/build-smart-card), [Unsecured Charge Card](/v2/docs/build-charge-card), and [Revolving Credit Card](/v2/docs/build-revolving-credit-card).

### Who Decides What

| Responsibility | Who |
| - | - |
| **Authorization decisions** | Synctera, against available balance, account standing, spend controls, address verification, and fraud rules. You can join the auth flow and decide per transaction if you need to. |
| **Funding** | The customer, through deposits into their account. |
| **Spend limits** | You, through spend controls on the account or the card. |
| **Disputes** | You raise them; Synctera works the case with the network. |

## API Flow

This guide follows the virtual-first pattern Synctera recommends: the customer gets a virtual card the moment onboarding completes, and a physical card arrives a few days later.

The `curl` examples assume you have set up `baseurl` and `apikey` environment variables. See [Base URL](/v2/reference/environments) and [Authentication](/v2/reference/authentication). Identifiers produced by earlier steps are written like `{ACCOUNT_ID}`.

```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart LR
  P["Person<br/>KYC ACCEPTED"] --> A["CHECKING account<br/>is_card_enabled: true"]
  A --> V["Virtual debit card<br/>active immediately"]
  A --> F["Physical debit card<br/>activated on arrival"]
```

### Step 1 — Create and Verify the Customer

Create a personal customer and run KYC. The customer must reach a `verification_status` of `ACCEPTED` before they can hold an account or use a card.

See [Create a Personal Customer](/v2/docs/create-a-personal-customer) and [KYC/KYB Verification](/v2/docs/kyc-kyb-verification).

Record the disclosures your program requires as part of onboarding — typically the USA Patriot Act notice, E-Sign consent, the privacy notice, and your deposit account agreement. See [Record Disclosure Acceptance](/v2/docs/record-disclosure-acceptance).

We refer to the resulting person's UUID as `{CUSTOMER_ID}`.

### Step 2 — Create an Account Template

The template defines the shape of every checking account you open for this program. Cards must be enabled on it.

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X POST "$baseurl/v0/accounts/templates" \
    -H "Authorization: Bearer $apikey" \
    -H 'Content-Type: application/json' \
    --data-binary '{
      "name": "consumer debit checking",
      "description": "Checking accounts backing consumer debit cards",
      "is_enabled": true,
      "template": {
        "account_type": "CHECKING",
        "bank_country": "US",
        "currency": "USD",
        "is_ach_enabled": true,
        "is_card_enabled": true,
        "is_p2p_enabled": true,
        "overdraft_limit": 0
      }
    }'
  ```
</CodeGroup>

Note the returned `id` — we refer to it as `{ACCOUNT_TEMPLATE_ID}`.

<Tip>
  You only build the template once, not once per customer. If you want every account in this program to carry the same spending limits or fee structure, attach a `spend_control_id` and a fee product to the template now — accounts inherit them at creation. See [Spend Controls](/v2/docs/spend-controls-guide) and [Fees and Rewards](/v2/docs/fees-and-rewards).
</Tip>

### Step 3 — Create the Account

Create the checking account from the template, with the customer as its holder. See [Create Accounts](/v2/docs/create-accounts-guide) for the full request and for account relationships.

We refer to the resulting account's UUID as `{ACCOUNT_ID}`.

### Step 4 — Find Your Card Product

List your card products and pick the debit product you intend to issue against. You need one product per form — a virtual product and a physical product.

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X GET "$baseurl/v2/cards/products" \
    -H "Authorization: Bearer $apikey"
  ```
</CodeGroup>

Check that `active` is `true`, and note the `id` of each. We refer to them as `{VIRTUAL_CARD_PRODUCT_ID}` and `{PHYSICAL_CARD_PRODUCT_ID}`. See [Card Products](/v2/docs/card-products) for what each field on the product controls.

### Step 5 — Issue a Virtual Card

Issue the virtual card as the last step of onboarding, so the customer can spend immediately.

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X POST "$baseurl/v2/cards" \
    -H "Authorization: Bearer $apikey" \
    -H 'Content-Type: application/json' \
    --data-binary '{
      "type": "DEBIT",
      "card_details": {
        "form": "VIRTUAL",
        "account_id": "{ACCOUNT_ID}",
        "customer_id": "{CUSTOMER_ID}",
        "card_product_id": "{VIRTUAL_CARD_PRODUCT_ID}"
      }
    }'
  ```
</CodeGroup>

Virtual cards activate automatically — the card comes back `ACTIVE`, with no activation step.

Show the card details to the customer with the [Reveal Card widget](/v2/docs/card-widgets-reveal), and prompt them to set a PIN with the [Set PIN widget](/v2/docs/card-widgets-set-pin).

Then prompt the customer to add the card to Apple Pay or Google Wallet. See [Digital Wallets and Tokenization](/v2/docs/digital-wallets).

### Step 6 — Issue a Physical Card

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X POST "$baseurl/v2/cards" \
    -H "Authorization: Bearer $apikey" \
    -H 'Content-Type: application/json' \
    --data-binary '{
      "type": "DEBIT",
      "card_details": {
        "form": "PHYSICAL",
        "account_id": "{ACCOUNT_ID}",
        "customer_id": "{CUSTOMER_ID}",
        "card_product_id": "{PHYSICAL_CARD_PRODUCT_ID}",
        "emboss_name": {
          "line_1": "Jane Smith"
        },
        "shipping": {
          "method": "LOCAL_MAIL",
          "recipient_name": "Jane Smith"
        }
      }
    }'
  ```
</CodeGroup>

If you omit `emboss_name`, the card is embossed with the customer's first and last name. If you omit `shipping.address`, the card goes to the customer's shipping address on file.

<Tip>
  For customers who have specified a chosen name, set `emboss_name` explicitly with their chosen and last name rather than relying on the default.
</Tip>

### Step 7 — Track Fulfillment

Subscribe to `CARD.*` webhooks. You receive `CARD.CREATED` on issuance and `CARD.UPDATED` as the card moves through `ORDERED`, `SHIPPED`, and any rejection, which is what you need to keep the customer informed. See the [Webhooks guide](/v2/docs/webhooks-guide).

### Step 8 — Activate the Physical Card

When the card arrives, the customer proves possession.

See [Activate a Card](/v2/docs/issue-a-card#activate-a-card) for the details and trade-offs.

The physical card keeps the PIN the customer already set on the virtual card only if the physical card was issued as a reissuance of the virtual card. Issued independently, as here, it needs its own PIN — prompt for one at activation.

## Running the Program

### Authorization and Declines

Synctera evaluates each funding request against the available balance, account standing, spend controls, address verification, and fraud rules. A decline carries a `data.reason` naming which check failed — `INSUFFICIENT_FUNDS`, `SPEND_CONTROL_VIOLATED`, `ADDRESS_VERIFICATION_FAILED`, and so on.

If you hold state Synctera does not, you can join the authorization flow and return an approve or decline decision per transaction. See [FinTech in the Auth Flow](/v2/docs/card-transactions#fintech-in-the-auth-flow).

### Spend Controls

Spend controls limit how much can be spent, over what window, on which payment types, and at which merchant categories. They attach to the **account**, so if you need per-card limits, give each card its own account under a funding hierarchy. See [Spend Controls](/v2/docs/spend-controls-guide) and [Card-Account Relationship and Funding Hierarchies](/v2/docs/card-accounts-funding).

### Card Lifecycle

The rest of the lifecycle is covered in [Manage a Card](/v2/docs/manage-a-card):

* **Lock and unlock** a card when a customer misplaces it
* **Reissue** on expiration, loss, theft, or damage
* **Terminate** when the customer closes the card

Set up expiration reissuance early. Use [List Cards](/v2/reference/listcards) with the `expires_before` filter to find cards approaching expiry, and reissue them with `EXPIRATION` before the date arrives — the replacement keeps the same PAN and PIN, and inherits the customer's digital wallet tokens, so the customer notices nothing.

### Disputes

Cardholders can dispute any card transaction. Raising a dispute opens a case in the Synctera Console and starts the investigation. See [Card Transaction Disputes](/v2/docs/card-transaction-disputes).