Card Issuing That Spends From a Crypto or Fiat Balance

Most teams discover the same thing once they start scoping a card: the card is the easy part. The hard part is everything behind it, the authorization logic, the funding model, the compliance perimeter, and the question of where the money actually lives when a user taps to pay.

This guide walks through how card issuing works end to end, the difference between an issuer and an acquirer, what you actually need to launch a program, and one design choice that changes the whole picture: a card that spends directly from a crypto or fiat balance instead of a pre-funded pool. If you are scoping a broader launch, start with our guide on how to build a crypto and fiat payment platform, then use this piece for the card layer.

What is card issuing?

Card issuing is the process of creating and distributing payment cards, virtual or physical, that a cardholder can use to spend from an account. The issuer authorizes every transaction, moves the funds, and carries the associated risk and compliance duties.

In practice, “issuing” is not a single action. It is a program: a set of rules for who gets a card, how it is funded, what it can spend on, and how each purchase is authorized in real time. The card itself, the piece of plastic or the token in a wallet, is just the visible tip of that program.

How card issuing works, end to end

At a high level, issuing follows one loop: a card is created and linked to a funding source, and every purchase is routed by the card network back to the issuer for a real-time decision. The issuer checks limits, balance and risk in milliseconds, then approves or declines.

Here is the full path a card takes, from setup to a completed purchase.

Stage	What happens	Who acts
Program setup	Define card rules, funding, limits and branding	You + issuing platform
Card creation	A card is generated and linked to a user and a funding source	Issuing platform
Provisioning	Virtual card is instant; physical card is manufactured and shipped	Issuing platform + manufacturer
Authorization	Network routes each purchase to the issuer for an approve or decline	Card network + issuer
Clearing and settlement	Funds are reconciled and settled between issuer and acquirer	Issuer + acquirer via network
Lifecycle	Freeze, replace, adjust limits, close	You, through the API

The table above is also a good mental model for where your engineering effort goes: almost none of it is the card, and almost all of it is authorization, funding and lifecycle.

Issuer vs acquirer vs the card networks

The issuer works on the cardholder side and the acquirer works on the merchant side, while the card network sits in the middle and routes messages between them. Confusing these three is the most common early mistake.

Role	Whose side	Core job
Issuer	Cardholder	Creates cards, authorizes spend, manages the account and funds
Acquirer	Merchant	Enrolls merchants, collects the payments they receive
Card network	Neither	Routes authorization and settlement messages between issuer and acquirer

If you are building a product where your users hold a balance and spend it, you are on the issuing side. You are not enrolling merchants, so you do not need to be an acquirer. What you need is access to an issuing program and a way to authorize transactions against your users’ funds.

What you need to issue cards

To issue cards you need five things: access to a card program, a processor to authorize and settle, PCI DSS compliant handling of card data, KYC and AML on your users, and a funding model. The question is whether you assemble these yourself or get them through one platform.

There are two broad routes to a live program.

Run your own program. You obtain the licenses, become a network member, and stand up processing and PCI infrastructure yourself. This gives maximum control and better long-run economics at scale, but it is slow, capital-heavy, and only makes sense at high volume.

Use BIN sponsorship through a Card-as-a-Service platform. A licensed institution lets you issue under its Bank Identification Number and network membership, and a platform gives you the API, processing and compliance plumbing. You own the product and the user experience; the regulated relationship rides on the sponsor.

Approach	Time to launch	Control	Best for
Own program and license	Long (many months)	Highest	High-volume issuers with regulatory resources
BIN sponsorship + Card-as-a-Service	Weeks	High on product, shared on rails	Most fintechs and marketplaces

For the vast majority of teams, BIN sponsorship through a platform is the right call. It is the same logic as the broader build-versus-buy decision: build the product your users come for, and integrate the regulated rails that would look identical at any competent fintech. For the licensing side of that decision, see licenses to move crypto and fiat: MSB, money transmitter, EMI and MiCA.

Card types you can issue

Cards fall into four product families, prepaid, debit, credit, and corporate or expense cards, and each can be virtual, physical, or both. The right type follows your funding model, not the other way around.

Card type	Spends from	Typical use
Prepaid	A loaded balance	Wallets, payouts, gig and creator payments
Debit	A linked account balance	Neobank accounts, everyday spend
Credit	An extended line of credit	Lending products, revolving credit
Corporate / expense	Company funds with per-user controls	Business spend, teams, procurement

Virtual cards are provisioned instantly and are ideal for online spend, one-time tokens and wallet payments. Physical cards, plastic or metal, matter when your users pay in person or expect a premium object. Most programs offer both from the same account.

Spending straight from a crypto or fiat balance

The design choice that changes everything is binding the card to a real-time balance rather than a pre-funded pool. When the card authorizes against the live balance, there is no float to manage, no pre-funding to reconcile, and value stays where the user controls it until the moment of spend.

This is where a unified multi-currency ledger pays off. A card linked to a unified balance can spend from local fiat or from a stablecoin position, with conversion handled at authorization. The user tops up in whatever they hold; the card spends in the merchant’s currency.

In a non-custodial architecture this also changes your risk profile. Because the user keeps control of their own funds and each movement needs their approval, you run the card program without holding customer money on your balance sheet. That is a different regulatory conversation from a custodial float account, and it is worth understanding the trade-offs in custodial vs non-custodial custody.

Creating a card that spends from a balance is a single API call. A realistic request looks like this.

curl https://api.tokelia.com/v1/cards \
  -H "Authorization: Bearer $API_KEY" \
  -H "Idempotency-Key: card_req_9f2c1a" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "usr_8Kd2p",
    "type": "virtual",
    "funding_source": "balance_usdc_primary",
    "currency": "USD",
    "spend_controls": {
      "per_transaction_limit": 50000,
      "daily_limit": 200000,
      "allowed_categories": ["retail", "travel", "software"]
    },
    "three_d_secure": true
  }'

Two details matter here. The Idempotency-Key header means a retried request never creates a duplicate card, which is essential when networks time out. And funding_source points at the user’s balance directly, so authorization runs against real-time funds rather than a separate wallet you have to keep topped up. A webhook then confirms every later event (authorization, decline, settlement) so your ledger stays in sync.

Compliance: KYC, AML and PCI DSS

Every issuing program carries three compliance duties: verifying who holds the card (KYC and AML), protecting card data (PCI DSS), and monitoring spend for fraud and sanctions. These are not optional add-ons; they are the price of touching the card networks.

KYC and AML run at onboarding and continue through the life of the card, with sanctions and PEP screening and transaction monitoring. For the full picture of how this works across crypto and fiat, see how KYC and AML work for crypto and fiat payments.

PCI DSS governs how card data (the PAN, CVV and PIN) is stored, transmitted and displayed. The cleanest way to handle it is to never touch raw card data yourself: a platform that tokenizes sensitive details and serves them through a compliant vault keeps most of the PCI burden off your systems. Fraud controls (velocity rules, 3-D Secure, freeze and geo controls) sit on top.

Costs, time to market and the interchange model

Card economics have two sides: the costs of running the program, and interchange revenue earned on spend. Interchange is the fee the merchant’s side pays on each transaction, part of which flows back to the issuing program, and it is the reason issuing can be a revenue line rather than a cost center.

Cost or revenue line	Direction	Notes
Program setup	Cost	One-time, varies by provider
Per-card fee	Cost	Virtual is cheapest; plastic and metal cost more
Transaction / processing	Cost	Per-authorization and settlement
Network fees	Cost	Set by the card network
Interchange	Revenue	Share of spend flows back to the program

Exact numbers vary by market, volume and program, so treat this as a framework rather than a quote, and confirm the economics with your provider. On timing, a Card-as-a-Service integration lets teams experienced with REST APIs reach a working card flow in weeks rather than the many months a self-licensed program takes.

A note on Mexico and regulated markets

In Mexico, card issuing generally involves a regulated entity, a bank or an electronic payment funds institution (IFPE) authorized under the Fintech Law and supervised by the CNBV, usually with participation in a card network. Companies without a license typically issue by partnering with a licensed sponsor.

This pattern repeats across markets: the regulated perimeter is set locally, and the fastest compliant route for a fintech is almost always to issue through a licensed partner rather than to obtain issuing authorization directly. Thresholds, categories and requirements evolve, so confirm the current framework in each market with local counsel before you commit a launch date.

Where Tokelia fits

Tokelia issues virtual, plastic and metal cards that spend directly from a non-custodial crypto or fiat balance, with instant send to any card, behind one API with webhooks, idempotency and a sandbox. Compliance (KYC/AML, sanctions screening and PCI-safe handling of card data) is built into the base stack rather than sold as add-ons. Money services are provided by Tokelia LLC, registered as a Money Services Business with FinCEN, with regulated banking delivered by licensed institutions, so you launch a card program under your own brand without holding customer funds or wiring together a separate processor, custodian and KYC vendor.

If you are scoping a card program, the fastest way to pressure-test it against your own funding model is to walk a real flow with our team. Talk to us and get a sandbox key.