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

# Prepaid Card

> A prepaid card is a stored-value card. Funds are loaded onto it in advance and the cardholder can only spend what is loaded — there is no deposit relationship and no credit line behind it.

Prepaid cards reach customers that debit and credit products cannot. They need no credit check and, for some types, no bank account, which makes them the usual instrument for gifting, disbursements, and serving the unbanked and underbanked.

In the Synctera platform a prepaid card is attached to a **prepaid account**. The account is a ledger record rather than a deposit account: the balance is the card. Prepaid cards are restricted from debiting the account directly and are limited to card spend.

Prepaid cards are either **reloadable** or **non-reloadable** - see details below.

## Overview

### Key Concepts

<AccordionGroup>
  <Accordion title="Stored value and the prepaid account">
    A prepaid card spends from a balance loaded in advance, not from an ongoing deposit relationship. The linked account uses the `PREPAID` account type, and the card uses the `PREPAID` card type — the same card type covers both reloadable and non-reloadable cards.

    Because the balance is the product, prepaid accounts restrict which payment rails are available and how funds can arrive. Cardholders are not given the account number, which is what keeps unsupported inbound transfers out.
  </Accordion>

  <Accordion title="Account programs">
    Prepaid accounts carry funding, spend, and rail restrictions that must hold for the life of the account. Those are enforced by an **account program** — a set of characteristics that stay immutable across the account's lifecycle, applied at the account template level.

    Synctera sets up the account program and the matching account template during onboarding, based on whether your product is reloadable or non-reloadable. Account programs use spend controls, rail restrictions, and where applicable bank-enforced KYC requirements.

    This means almost no setup work on your side: pass the `account_template_id` you were given at onboarding, and every account created from it inherits the right behavior. See [Account Programs](/v2/docs/create-accounts-guide#account-programs).
  </Accordion>

  <Accordion title="Funding channels and load limits">
    Funding is restricted to methods that do not require the cardholder to know an account number — direct deposit, cash and check deposits, internal transfers, and AFT/OCT.

    The card networks impose load limits, which differ by type:

    | | Reloadable | Non-reloadable |
    | - | - | - |
    | Daily cash | \$5,000 | \$500 |
    | Daily electronic | No restriction | \$500 |
    | Monthly combined | \$150,000 | Not applicable |

    For a non-reloadable product, a one-time funding spend control is applied by the account program and cannot be changed at the account level.
  </Accordion>
</AccordionGroup>

### Reloadable and Non-Reloadable

This is the decision that shapes everything else about the program.

| | Reloadable | Non-reloadable |
| - | - | - |
| Loading | Topped up repeatedly for ongoing use | Loaded once, cannot be replenished once spent |
| Best for | The unbanked and underbanked, payroll and EWA, teens and students, gig payouts, corporate and government disbursements | Gifting, privacy, one-off purchases, store credit, refunds, incentives |
| Account type | `PREPAID` | `PREPAID` |
| KYC | Required | Generally not required — some banks may still require it |
| Cardholder name on card | Required | Not required; cards can carry a generic program name |
| Cash and ATM access | Yes | No |
| Inbound AFT | Allowed | Not allowed |
| Tokenization | Supported | Supported with restrictions — one device, no card-on-file, USD only |
| Cashback at point of sale | Allowed | Not allowed |
| Merchant acceptance | Wide, though some high-risk and subscription merchants block prepaid | Narrowest of the card types; many online merchants block anonymous cards that cannot be verified by AVS |
| Dispute rights | Yes, under Regulation E | Limited or none |

<Note>
  A non-reloadable card cannot be converted to a reloadable one. If a customer qualifies for a reloadable product later, issue a new account and a new card.
</Note>

### How It Differs from a Debit Card

| | Prepaid | Debit |
| - | - | - |
| Funds come from | A balance loaded in advance | The customer's deposit account |
| Underlying account | A prepaid ledger account; the balance is the card | A deposit account the customer holds |
| Funding channels | Restricted to methods not requiring an account number | No restrictions |
| Load limits | Set by the network | None |
| Payment rails | Card spend only; other rails disabled | ACH, wire, P2P, card |
| MCC restrictions | Common, especially for non-reloadable | Rare, use-case dependent |

See [Debit Card](/v2/docs/build-debit-card).

### What Synctera Configures for You

Prepaid programs need more platform-side setup than debit, and almost all of it happens before you write code.

| Object | What it does | Who sets it up |
| - | - | - |
| Account program | Fixes the account type, KYC requirements, payment rails, and spend controls for the life of the account | Synctera, during onboarding |
| Account template | Carries the account program, so accounts created from it inherit its settings | Synctera, during onboarding |
| Spend controls | Enforce the one-time funding restriction on non-reloadable products and any load limits | Synctera, as part of the account program |
| Card product | The BIN, network product type, and card art for your prepaid cards | Synctera, with your sponsor bank and the network |

Prepaid programs must be registered and approved with the card network, and the card art has network-specific requirements. Your Implementation & Onboarding manager handles both.

<Note>
  Prepaid cards require additional configuration for your tenant on Synctera. Work with your Synctera Implementation & Onboarding manager to get set up.
</Note>

## API Flow

Once your account program and template exist, issuing a prepaid card is a short sequence.

```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart TB
  A["Create the customer"] --> B["Record disclosures"]
  B --> C["Verify the customer"]
  C --> D["Open the prepaid account<br/>with your account_template_id"]
  D --> E["Issue the card"]
  E --> F["Load funds"]
```

The `curl` examples assume you have set up `baseurl` and `apikey` environment variables. See [Base URL](/v2/reference/environments) and [Authentication](/v2/reference/authentication).

### Step 1 — Create the Customer

Collect the customer's personal information and create the person. See [Create a Personal Customer](/v2/docs/create-a-personal-customer).

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

### Step 2 — Record Disclosures

Record the customer's acknowledgement of each required disclosure, one call per disclosure. See [Record Disclosure Acceptance](/v2/docs/record-disclosure-acceptance).

### Step 3 — Verify the Customer

**Reloadable** products require KYC. The customer must reach a `verification_status` of `ACCEPTED` before the account can be opened. See [KYC/KYB Verification](/v2/docs/kyc-kyb-verification).

**Non-reloadable** products generally do not require KYC, though your sponsor bank may still require document verification. Where KYC is not required, the account program carries the exemption — you do not handle it in your own code.

Where your sponsor bank requires enhanced due diligence, upload it against the customer record. See [Enhanced Due Diligence](/v2/docs/enhanced-due-diligence-guide).

### Step 4 — Open the Prepaid Account

Create the account from the template you were given at onboarding. That template carries the account program, so the account inherits the correct funding limits, rail restrictions, and spend controls.

<CodeGroup>
  ```shell Shell theme={"system"}
  curl -X POST "$baseurl/v2/accounts" \
    -H "Authorization: Bearer $apikey" \
    -H 'Content-Type: application/json' \
    --data-binary '{
      "account_type": "PREPAID",
      "account_template_id": "{ACCOUNT_TEMPLATE_ID}",
      "customer_id": "{CUSTOMER_ID}"
    }'
  ```
</CodeGroup>

Use the reloadable or non-reloadable template as appropriate — they are different templates carrying different programs. See [Create Accounts](/v2/docs/create-accounts-guide).

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

### Step 5 — Issue the Card

Issue against the prepaid account with `"type": "PREPAID"`. Virtual and physical cards are both supported.

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

For a non-reloadable card where no cardholder name is required, the card carries a generic program name instead. Physical cards require activation; virtual cards do not. See [Issue a Card](/v2/docs/issue-a-card).

### Step 6 — Load Funds

Load the card through one of the permitted funding channels. The common pattern is an internal transfer from a pre-funded account you maintain on the platform. See [Internal Transfers](/v2/docs/internal-transfer-guide).

For a non-reloadable product, the account program's spend control permits a single funding transaction. Further load attempts are declined.

### Step 7 — Ship in Bulk, If Applicable

Gift and incentive programs frequently ship cards in bulk to a business for on-site distribution. Cards can be issued against a business without naming a cardholder, then assigned to individuals later with [Update Card](/v2/reference/updatecard).

See [Bulk Card Orders](/v2/docs/bulk-card-orders).

## Running the Program

### Spend and Restrictions

Prepaid accounts allow card spend and disable the other payment rails. MCC restrictions are common — particularly on non-reloadable products, where high-risk categories and merchants that place large authorization holds, such as travel, lodging, and fuel, are often blocked.

See [Spend Controls](/v2/docs/spend-controls-guide).

### Tokenization

Both types can be added to a digital wallet, but non-reloadable cards carry network restrictions: one device, no card-on-file, and USD transactions only. Tokenization requires an email address and phone number for the cardholder.

See [Digital Wallets and Tokenization](/v2/docs/digital-wallets).

### Fees

Fees are more common on prepaid than on debit — activation, monthly maintenance, reload, ATM, inactivity, and FX. Configure them as rules bundled into a fee product linked to the account template. See [Fees and Rewards](/v2/docs/fees-and-rewards).

### Statements

Sending prepaid cardholders monthly statements is not a requirement. It is, however, a requirement to make accessible the card's full online transaction history.

See [Statements](/v2/docs/statements-guide).

### Disputes

Reloadable cards carry Regulation E dispute rights. Non-reloadable cards have limited or no protection, and what applies may depend on merchant policy. See [Card Transaction Disputes](/v2/docs/card-transaction-disputes).