Crypto-Debit Card Development: From Concept to Launch

Crypto-Debit Card Development: From Concept to Launch

Developing a crypto-debit card builds a bridge between a DeFi wallet and the traditional Visa/Mastercard payment infrastructure. The user holds USDC or ETH in their crypto balance; when paying with the card, the system automatically converts the required amount into fiat and processes the transaction via banking rails. To the merchant, it looks like a regular card—the user pays with crypto. We have delivered such projects for nine Web3 companies, each with unique requirements for stack, jurisdiction, and cashback. With 9 successful projects and over 5 years of experience in card issuing, we guarantee compliance with all relevant regulations. Contact us to evaluate your idea.

Architectural Components

The product consists of several independent layers, each requiring its own technical solution and regulatory coverage.

BIN Sponsorship and Card Issuing

Visa and Mastercard rarely work with crypto companies directly. You need a bank sponsor or card program manager that holds a BIN (Bank Identification Number) and has direct participation in card networks.

Options:

• Marqeta — API-first card issuing, works with Web3 companies. Requires a banking partnership. Marqeta's API is 3x faster than traditional processors for authorization.
• Stripe Issuing — available in 30+ countries, quick start, but limited customization.
• Moorwand, Railsbank — European issuers, more flexible for cryptocurrencies.
• Binance Card, Crypto.com Visa — ready-made white-label solutions, but no customization.

For launching your own product, the most realistic path: Marqeta API + a banking partner (Metropolitan Commercial Bank, Banking Circle, etc.).

Crypto Custody

User balances are held in cryptocurrency. Two approaches:

On-chain wallets. Each user has an on-chain address (or a virtual account in a segregation system). USDC is stored as-is; conversion happens at the time of transaction.

Off-chain accounting. User funds are kept in a common pool; an internal ledger tracks shares. Cheaper to operate, but more complex from a regulatory perspective.

Conversion at Transaction Time

Key point: Visa authorization occurs within 1–3 seconds. In that time you must:

1. Receive an authorization request from Marqeta (amount in USD)
2. Check the user's balance in USDC/ETH
3. Lock (hold) the required crypto amount
4. Respond with approve or decline

The conversion rate is pre-committed: at authorization, the rate is fixed and the amount is held. At settlement (usually T+1), actual conversion occurs. This means you need a buffer for rate fluctuations—or instant settlement.

interface AuthorizationRequest {
  cardId: string;
  transactionAmount: number;  // in USD
  merchantCategory: string;
  merchantName: string;
  transactionId: string;
}

async function handleAuthorization(req: AuthorizationRequest): Promise<AuthDecision> {
  const user = await db.getUserByCardId(req.cardId);
  
  // Get current rate with a small slippage buffer (0.5%)
  const cryptoPrice = await priceService.getPrice(user.preferredCrypto, 'USD');
  const requiredCrypto = (req.transactionAmount / cryptoPrice) * 1.005;
  
  const balance = await walletService.getBalance(user.id, user.preferredCrypto);
  
  if (balance < requiredCrypto) {
    return { decision: 'DECLINE', reason: 'INSUFFICIENT_FUNDS' };
  }
  
  // Lock funds
  await walletService.hold(user.id, user.preferredCrypto, requiredCrypto, req.transactionId);
  
  return { decision: 'APPROVE', authorizedAmount: req.transactionAmount };
}

What Regulatory Requirements Must Be Met?

A crypto card is one of the most regulatorily complex crypto services. Requirements depend on jurisdiction:

EU (MiCA + EMD2/PSD2): Requires an Electronic Money Institution (EMI) license for issuing e-money, or working through a licensed partner. Typical EMI application costs €25,000–€50,000.

UK (FCA): Electronic Money Institution authorisation or Small Electronic Money Institution.

USA: Money Transmitter License (MTL) in each state, or working through a licensed partner. Obtaining MTL in 50 states takes 1–2 years and significant investment.

Minimum path: Register an EMI license in Lithuania or Estonia (EU), use passporting across the EU. Partner with Marqeta for physical infrastructure.

KYC/AML

Full KYC is mandatory:

• Identity verification (passport + selfie) — Sumsub, Jumio, Onfido
• Sanctions list checks (OFAC, EU, UN) — Chainalysis, Elliptic
• Transaction monitoring (AML scoring) — Chainalysis KYT
• Enhanced Due Diligence for large transactions

Physical vs. Virtual Card

Virtual card — only details (number, CVV, expiry). For online purchases. Cheaper to produce (70% cost reduction), issued instantly.

Physical card — plastic with a chip. Requires a card printer and personalization. Production cost depends on volume. Issue time 1–2 weeks.

Most crypto cards start with virtual (90% of our clients) and add physical on demand.

Technical Architecture

Mobile/Web App (React Native / Next.js)
    ↓
API Server (Node.js + TypeScript)
    ├── Card Management Service
    │   └── Marqeta API (cards, limits, statuses)
    ├── Authorization Handler (webhook from Marqeta)
    │   └── < 500ms response time (critical!)
    ├── Crypto Custody Service
    │   ├── Internal ledger (PostgreSQL)
    │   └── On-chain settlement (Alchemy + ethers.js)
    ├── Price Oracle Service
    │   └── Chainlink + CoinGecko fallback
    ├── KYC Service
    │   └── Sumsub API
    └── AML/KYT Service
        └── Chainalysis API

Cashback Program in Crypto

A differentiating feature: cashback is paid in crypto (native project token, BTC, or USDC). Typical cashback rates range from 1% to 5% depending on merchant category. Requires:

• A smart contract for accrual (if cashback in own token — ERC-20 with minting rights in the system)
• An accumulation and withdrawal mechanism
• Transparent rules (merchant categories, cashback percentage, limits)

Supported Networks and Assets

Launch typically starts with USDC (stablecoin, no exchange rate risk while holding). Then add ETH, BTC. Each new asset requires a separate price oracle and exchange rate risk management.

Multi-chain support matters: USDC on Polygon is cheaper in transactions than on Ethereum mainnet (fees ~$0.01 vs $5).

Timelines and Estimation

Technical development alone (without regulatory path) takes 4–6 months. Full launch including licensing takes 12–18 months.

What's Included in the Work

• Business requirements analysis and optimal BIN sponsor/issuer selection
• Architecture development: card management, authorization handler, custody service
• Integration with Marqeta/Stripe Issuing and card program setup
• KYC/AML service integration (Sumsub, Chainalysis)
• Implementation of on-chain wallets and smart contracts for cashback
• Legal support for obtaining an EMI license (Lithuania, Estonia) or partnering with a licensee
• Load testing and authorization speed optimization (< 500 ms)
• Ongoing post-launch support: transaction monitoring, price oracle updates, regulatory compliance adjustments

With 9 successful crypto card projects delivered and over 5 years of proven experience, we guarantee a smooth launch. Contact us to evaluate your project.

We develop crypto wallets turnkey — from custodial solutions for fintech to smart contract accounts on EIP-4337. 5+ years in blockchain development, 40+ projects implemented. Let's examine which architecture to choose for your task and why MPC or Account Abstraction solve the private key problem that MetaMask and classic HD wallets could not close.

Why are classic wallets dangerous for business?

A seed phrase in a browser extension is the only way to restore access. For retail users, this is a barrier to entry (lost phrase = lost money). For corporate treasuries, it is incompatible with compliance (KYC/AML, role model, multisignature). Any single key leak compromises all funds. These risks are built into the architecture, not poor UX.

We eliminate them at the protocol level: MPC wallets (key never fully assembled), smart contract wallets (authorization logic in code), hardware HSM for institutional storage. Details below.

What is the real difference between custodial and non-custodial?

Custodial — the provider stores the private key. User authenticates via email/password/OAuth. Recovery is trivial, KYC/AML built-in. For centralized financial applications, often the only regulatory acceptable option. Risk: single point of failure (e.g., Bitfinex hack — $72M, FTX — $600M+ client funds).

Non-custodial — keys are with the user. Provider has no access to funds. Storage responsibility falls on the user. For 99% of people, this model is unworkable without additional protection — hence MPC.

MPC wallets: the key that doesn't exist

Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly sign a transaction without revealing their partial secrets. The private key never exists in its assembled form.

Standard scheme: 2-of-3 MPC between user (share on device), provider server, and backup cloud storage. Transaction is signed by any two of three parties. Lost phone — recovery via server + cloud. Server compromised — attacker holds only one share, signing impossible.

TSS (Threshold Signature Scheme) is a concrete implementation of MPC for ECDSA/EdDSA. Algorithms: GG18, GG20, CGGMP21 (the latter is faster and has better security proofs). Libraries: tss-lib (Go, from Binance), multi-party-sig (Go, from Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC requires no on-chain changes — to the blockchain, the signature looks like a normal single-key signature. This saves gas and keeps the key management scheme confidential (not published in chain) — unlike multisig.

Account Abstraction (EIP-4337): smart contract as wallet

EIP-4337 completely changes the model: instead of EOA (Externally Owned Account), a smart contract Account is used. Authorization logic is in contract code, not in protocol cryptography. This opens up arbitrary signing logic, social recovery, session keys, sponsored transactions, and batch operations.

How the EIP-4337 stack works:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — a new type of object (not an L1 transaction). Bundler collects UserOps from an alternative mempool, packs them into one transaction, and sends to EntryPoint. EntryPoint calls validateUserOp on the Account contract — Account decides if the signature is valid.

Practical capabilities:

Social recovery. The contract stores a list of guardians (other addresses or a service). Lost key — guardians vote for replacement. Argent has used this scheme since 2020.

Session keys. A temporary key with limited rights: interaction only with a specific contract, until a certain date, up to a certain amount. For GameFi and dApps — user does not sign every micro-transaction.

Paymaster. A third-party contract pays gas for the user. Onboarding pattern: user does not hold ETH, gas is sponsored by dApp or taken from ERC-20 tokens.

Implementations: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). EntryPoint v0.6/v0.7 is deployed and active on Ethereum mainnet, Polygon, Arbitrum, Optimism. We guarantee compatibility with the latest contract versions.

What is a Hardware Security Module for corporate wallets?

For treasuries and institutional storage: HSM (Hardware Security Module). The key is generated and never leaves the secure chip. Signing happens inside the HSM. Hardware attestation is supported. Solutions used: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (for small volumes). Integration via PKCS#11 or cloud-specific API.

A combination of HSM + MPC is optimal for institutional use: key shares are stored in HSMs on different servers/jurisdictions, signing via TSS. This ensures compliance with regulatory requirements (e.g., for crypto custodians).

Integration with dApps: WalletConnect and standards

Any wallet must be able to interact with dApps. Standard: WalletConnect v2 (Sign API): QR code or deep link, peer-to-peer encrypted channel via relay server. For browser extensions: EIP-1193 (Ethereum Provider API).

On the frontend, we use wagmi + viem — one interface for MetaMask, WalletConnect, Coinbase Wallet, injected providers. For Account Abstraction: EIP-5792 (wallet capabilities) and EIP-7677 (paymaster service).

Development process

1. Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
2. Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
3. Development of Account contract (if EIP-4337) or integration of MPC library.
4. Backend — MPC coordination, session management, paymaster service (if needed).
5. Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
6. Integration with dApps — EIP-1193, WalletConnect v2.
7. Audit of contracts and cryptographic implementations — mandatory step. MPC libraries have known vulnerabilities (GG18 susceptible to attack with malicious participant without abort protocol). We use libraries with up-to-date security reviews (CGGMP21). Experience passing audits with Certik, Hacken, Trail of Bits — we have certificates.

What is included in the work (deliverables)

• Source code of smart contracts (Solidity/Rust) with documentation
• Backend MPC coordination service (Go or Rust) with API
• Mobile application (iOS/Android) or browser extension
• Integration with WalletConnect, Ledger/Trezor (if required)
• Preparation for security audit (vulnerability report)
• Administrator and user documentation
• Access to repository, CI/CD, monitoring (Tenderly, Etherscan API)
• Training of your team (2-3 sessions)
• Post-launch support — 1 month

Timeline and cost

Cost is calculated individually for your project. We will estimate within one day — contact us by email or Telegram. We provide a guarantee on code and timeline.

Typical mistakes in crypto wallet development (and how to avoid them)

• Using outdated MPC libraries — GG18 without abort protocol. Choose CGGMP21 or tss-lib with up-to-date audit reports.
• Tight coupling to a single blockchain — not abstracting for L2/sidechains. Use viem/wagmi for cross-chain.
• Ignoring MEV attacks — when using multisig without timelocks. Add tx simulation (Tenderly) and sandwiching protection.
• Lack of fallback recovery mechanism — for Account Abstraction, not setting up social recovery. Include from the first release.

We eliminate these pitfalls at the design stage — for each project, we create a threat model and security checklist.

Need a reliable wallet with no compromises? Get a consultation from our architect — we will analyze your task and propose an architecture with a precise estimate. Leave a request — we will respond within a day.