How to add debit cards to a neobank: program models, providers, and how cards meet your ledger

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.

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 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 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 typeWho issuesWhere the balance sitsWho funds itWhere BlindPay fits
Debit on a deposit accountPartner bank through a card providerDeposit account at the partner bankCustomer deposits and transfersPayouts in local currency when customers send money abroad
PrepaidPartner bank through a card providerPrepaid program balanceLoads from depositsVirtual accounts collect the deposits that become loads
Stablecoin-backedCard provider with a BIN sponsorStablecoin wallet the card spends fromUSDC or USDT in the walletVirtual accounts deliver USDC or USDT to that wallet; payouts cash out unspent balance

For the stablecoin-backed model, 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.

EventLedger effectSource
Deposit settlesCredit availablePayin webhook
Card authorizationMove amount to heldCard provider
Card captureDebit heldCard provider
Card refundCredit availableCard provider
Payout executedDebit availablePayout quote and webhook
Payout refundedCredit availablePayout webhook

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 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 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 before a customer gets the account.
  • Interchange. The Federal Reserve's Regulation II 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 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 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 cover the deposit side.

FAQ