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

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.

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.

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.

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

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.

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.

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.

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

API Flow

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

The curl examples assume you have set up baseurl and apikey environment variables. See Base URL and Authentication.

Step 1 — Create the Customer

Collect the customer’s personal information and create the person. See 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.

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.

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.

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.

Shell

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

Use the reloadable or non-reloadable template as appropriate — they are different templates carrying different programs. See Create Accounts.

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.

Shell

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

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.

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.

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.

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

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.

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.

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.

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.