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.

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.

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.

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.

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, Secured Smart Card, Unsecured Charge Card, and 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 and Authentication. Identifiers produced by earlier steps are written like {ACCOUNT_ID}.

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

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.

Shell

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
    }
  }'

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

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 and Fees and Rewards.

Step 3 — Create the Account

Create the checking account from the template, with the customer as its holder. See Create Accounts 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.

Shell

curl -X GET "$baseurl/v2/cards/products" \
  -H "Authorization: Bearer $apikey"

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

Shell

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}"
    }
  }'

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, and prompt them to set a PIN with the Set PIN widget.

Then prompt the customer to add the card to Apple Pay or Google Wallet. See Digital Wallets and Tokenization.

Step 6 — Issue a Physical Card

Shell

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"
      }
    }
  }'

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.

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

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.

Step 8 — Activate the Physical Card

When the card arrives, the customer proves possession.

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

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 and Card-Account Relationship and Funding Hierarchies.

Card Lifecycle

The rest of the lifecycle is covered in 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 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.