---
title: "How to add debit cards to a neobank: program models, providers, and how cards meet your ledger"
seoTitle: "How to add debit cards to a neobank in 2026"
description: "How to add debit, prepaid, or stablecoin-backed cards to a neobank: who issues, who funds, how card spend hits your ledger, what to ask a card provider."
date: "2026-10-18"
updated: "2026-10-18"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How to add a card program to a neobank"
  steps:
    - name: "Choose a card program model"
      text: "Decide between a debit card on a partner-bank deposit account, a prepaid card, or a stablecoin-backed card. The model decides who issues the card and where the spendable balance lives."
    - name: "Pick a card issuing provider"
      text: "Shortlist providers that bundle a BIN sponsor, an issuer-processor, and program management, and ask the questions in the checklist below."
    - name: "Connect card spend to your ledger"
      text: "Make your ledger the source of the available balance. Card authorizations place holds, captures post debits, and refunds post credits."
    - name: "Fund the card balance from deposits"
      text: "Route customer deposits, for example payins from virtual accounts, into the balance the card spends from, and credit the ledger when each deposit settles."
    - name: "Let customers cash out what they don't spend"
      text: "Offer a transfer to a bank account over local rails so card balances are never stuck."
    - name: "Pilot with low limits"
      text: "Launch to a small group with conservative spend limits, watch disputes and declines daily, then raise limits."
faq:
  - q: "How do you add debit cards to a neobank?"
    a: "Pick a card program model, sign with a card issuing provider that brings a BIN sponsor and an issuer-processor, and connect card events to your ledger so spend draws from the same balance as transfers. Fund that balance from customer deposits and let customers cash out to a bank account. Plan for disputes, fraud controls, and consumer protection rules from day one."
  - q: "Who issues the cards in a neobank card program?"
    a: "Card issuing comes from a card program provider such as an issuer-processor or program manager. In a neobank stack, BlindPay sits next to that provider: it collects deposits through US virtual accounts, converts them to USDC or USDT, and pays out in local currency over Pix, SPEI, ACH, SEPA, or SWIFT (POBO/COBO). Your ledger connects card spend with those flows."
  - q: "What is the difference between a debit card and a prepaid card in a neobank?"
    a: "A debit card draws from a deposit account, usually held at a partner bank in the customer's name or in a pooled account. A prepaid card draws from a balance loaded in advance. In the US both fall under Regulation E consumer protections, and prepaid accounts carry extra disclosure rules before the customer acquires the account."
  - q: "What is a stablecoin-backed card?"
    a: "A stablecoin-backed card is a Visa or Mastercard card whose spending balance is held in a stablecoin such as USDC. At checkout, the card program converts enough stablecoin to cover the purchase and the merchant receives local currency as usual. For a neobank, it lets customers spend dollar balances anywhere cards work without holding a US bank account."
  - q: "How long does it take to launch a neobank card program?"
    a: "Timelines depend on the provider and the program model. Working with a provider that bundles the BIN sponsor, processor, and program management is faster than assembling those roles yourself. Budget time for sponsor bank review of your compliance program, card design and network approval, ledger integration, and a pilot with low limits before a wider launch."
  - q: "Who is liable when a neobank customer's card is used without permission?"
    a: "In the US, Regulation E caps a consumer's liability for unauthorized debit transfers at $50 if they report a lost or stolen card within two business days of learning of it, and up to $500 after that. The financial institution investigates. Your card provider agreement decides how dispute work and losses are split between you and the provider."
---

To add debit cards to a neobank, choose a program model (debit, prepaid, or stablecoin-backed), sign with a card issuing provider that brings the BIN sponsor and processor, and make your ledger the single source of the spendable balance. BlindPay sits next to the card provider: it collects deposits into virtual accounts and pays out in local currency.

Cards are the most visible feature in a neobank and the one with the most moving parts. This guide covers the program models, a decision table, a reference flow from deposit to card spend to cash-out, and the questions to ask a card provider. It continues the [how to build a neobank](/resources/more/how-to-build-a-neobank) series.

**Key takeaways**

- The card program model decides who issues the card and where the spendable balance lives.
- Card issuing comes from a card provider: BIN sponsor, issuer-processor, and program manager roles.
- Your ledger holds the available balance. Card holds, transfers, and deposits all read from it.
- Fund the card from deposits and give customers a way to cash out. Stuck balances become support tickets.
- Plan for disputes and Regulation E before launch, not after the first chargeback.

## What card program models can a neobank choose?

Three models cover most neobanks. They differ in where the money sits when the customer taps the card.

1. **Debit card on a deposit account.** The card draws from a deposit account held at a partner bank. Familiar to US customers and tied to the partner bank's rules.
2. **Prepaid card.** The card draws from a balance loaded in advance. Simpler to set up in some programs, with its own disclosure rules.
3. **Stablecoin-backed card.** The card draws from a stablecoin balance, usually USDC, and the program converts at checkout. Useful for dollar accounts outside the US.

Each card network transaction runs through the same roles behind the scenes. [BIN sponsor vs issuer-processor vs program manager](/resources/more/bin-sponsor-vs-issuer-processor-vs-program-manager) explains who does what.

## Who issues, who funds, and where does BlindPay fit?

The card provider issues. Your customers' deposits fund. BlindPay moves the money around the card.

| Card program type | Who issues | Where the balance sits | Who funds it | Where BlindPay fits |
| --- | --- | --- | --- | --- |
| Debit on a deposit account | Partner bank through a card provider | Deposit account at the partner bank | Customer deposits and transfers | Payouts in local currency when customers send money abroad |
| Prepaid | Partner bank through a card provider | Prepaid program balance | Loads from deposits | Virtual accounts collect the deposits that become loads |
| Stablecoin-backed | Card provider with a BIN sponsor | Stablecoin wallet the card spends from | USDC or USDT in the wallet | Virtual accounts deliver USDC or USDT to that wallet; payouts cash out unspent balance |

For the stablecoin-backed model, [Bridge cards and BlindPay payouts](/resources/more/bridge-cards-and-blindpay-payouts) shows a full stack with wallet and network matching.

## How does a card fit into the neobank's money flow?

One balance, three ways to move it. Here is the reference flow for a stablecoin-backed card, the model that pairs most directly with BlindPay.

1. **Deposit.** A customer's employer sends dollars by ACH to the customer's BlindPay US virtual account.
2. **Conversion.** The deposit creates a payin. BlindPay converts it and delivers USDC to the wallet linked to that account, the same wallet the card spends from.
3. **Ledger credit.** A signed webhook reaches your backend. Your ledger credits the customer's available balance.
4. **Card authorization.** The customer taps the card. The card provider asks your systems, or its own balance view, whether funds are available. Your ledger places a hold.
5. **Capture.** The purchase clears. The hold becomes a debit.
6. **Cash out.** The customer sends the rest home. Your app requests a BlindPay payout quote over Pix, SPEI, ACH, SEPA, or SWIFT (POBO/COBO), shows the rate and fees, and executes on confirmation.
7. **Reconcile.** Daily, your ledger matches payins, card captures, refunds, and payouts against each provider's events.

The design rule: the ledger decides the available balance, never a live query to a provider at authorization time. Card decisions need answers in milliseconds.

## How do the Add money, card, and cash-out flows share one balance?

Every flow reads and writes the same customer journal.

| Event | Ledger effect | Source |
| --- | --- | --- |
| Deposit settles | Credit available | Payin webhook |
| Card authorization | Move amount to held | Card provider |
| Card capture | Debit held | Card provider |
| Card refund | Credit available | Card provider |
| Payout executed | Debit available | Payout quote and webhook |
| Payout refunded | Credit available | Payout webhook |

[Add money and withdraw flows](/resources/more/neobank-add-money-and-withdraw-flows) covers the screens and states customers see for deposits and cash-outs.

## What does a worked example look like?

Illustrative example with invented figures. Lucía, a remote worker in Mexico, uses a neobank with a stablecoin-backed card.

- Her US client pays $1,500 into her BlindPay US virtual account. After the deposit fee, the app credits her available balance.
- She spends $320 on card purchases during the month. Each one places a hold, then a debit.
- She sends $900 to her own Mexican bank account. The app shows a SPEI quote with the MXN amount and fees, she confirms, and the payout runs.
- About $280 stays in her balance for next month's card spend.

One balance, three flows, one ledger.

## What should you ask a card provider?

Ask these before you sign. They decide launch time, economics, and how much work lands on your team.

1. Which BIN sponsor issues the cards, and in which countries can cardholders live?
2. Which program models do you support: debit, prepaid, stablecoin-backed?
3. Which wallets and networks can a stablecoin-backed card spend from?
4. Who answers authorization requests: your balance view, or a webhook to our ledger?
5. How is interchange shared, and does the sponsor bank fall under Regulation II limits?
6. Who handles disputes and chargebacks, and how are fraud losses split?
7. Do you support tokenized wallets, card controls, and freezes from our app?
8. What KYC do you run, and can we reuse checks we already ran?
9. What are the minimums, setup fees, and per-card costs?
10. How long from contract to first live card, and what is the sponsor's review process?

[How to choose a stablecoin card issuing provider](/resources/more/how-to-choose-a-stablecoin-card-issuing-provider) goes deeper on question 3 and on provider comparisons.

## What compliance and fraud work comes with cards?

More than most teams expect. Cards bring consumer protection rules, network rules, and fraud patterns that transfers don't have.

- **Unauthorized use.** In the US, [Regulation E](https://www.law.cornell.edu/cfr/text/12/1005.6) caps consumer liability at $50 when a lost or stolen card is reported within two business days, and up to $500 after that.
- **Prepaid disclosures.** Prepaid accounts carry [pre-acquisition disclosure rules](https://www.law.cornell.edu/cfr/text/12/1005.18) before a customer gets the account.
- **Interchange.** The Federal Reserve's [Regulation II](https://www.federalreserve.gov/paymentsystems/regii-about.htm) limits debit interchange fees, with exemptions for certain small issuers. Your sponsor bank's size changes your revenue.
- **KYC.** The card provider and your payments provider each verify customers on their leg. Map who checks what so customers aren't asked twice for the same document.

This is educational content, not legal advice. Confirm your card obligations with counsel and your card provider.

## How do cards change neobank revenue?

Cards add interchange, the fee the merchant's side pays to the issuing side on each purchase. The issuer shares part of it with the program. The share depends on the program model, the sponsor bank, and your agreement. [How neobanks make money](/resources/more/how-neobanks-make-money) puts interchange next to FX margin, transfer fees, and subscriptions in one unit model.

## What are the common mistakes when adding cards?

- **Launching cards before money in and out work.** A card on an empty balance is a support problem.
- **Letting the card provider own the balance alone.** Without your own ledger, transfers and card spend drift apart.
- **Mismatched wallet or network.** A stablecoin card that spends from one network can't use deposits delivered on another.
- **No cash-out path.** Customers want unspent balances back in their bank account.
- **Ignoring disputes.** Every card program gets chargebacks. Staff and tooling should exist on day one.
- **High limits at launch.** Start low and raise limits as fraud data comes in.

## How does BlindPay fit next to a card program?

BlindPay is the money movement layer around the card. It doesn't sit in the authorization path. It fills the balance and empties it.

- **Money in.** US virtual accounts in each customer's own name, with their own routing and account numbers, accepting ACH, wire, and SWIFT. Each deposit creates a payin and delivers USDC or USDT to the linked wallet, the wallet a stablecoin-backed card can spend from. Accounts cost $1.50 per month each.
- **Money out.** Payouts over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO), with quotes that lock the rate and fees for 5 minutes. No pre-funding.
- **Compliance.** KYC, KYB, and sanctions screening in the API, so the payments leg is verified without a separate vendor.
- **Signals for your ledger.** Signed webhooks for payins and payouts, ready to post as ledger entries.

Pair it with the card provider of your choice and keep your ledger as the bridge between them. [The neobank tech stack guide](/resources/more/neobank-tech-stack-build-vs-buy) shows where each provider sits.

## What to do next

Pick your card program model, send the 10 questions to two card providers, and build the deposit and cash-out legs on a BlindPay development instance while you wait. The [virtual accounts docs](/docs/virtual-accounts) cover the deposit side.