Crypto cards: the landscape and how to add them to your product

When a card program fails, the wallet often keeps working. That single observation is enough to redesign how most teams “add a card.”

Crypto cards: the landscape and how to add them to your product — for engineers and product leads who already ship wallets, exchanges, or fintech apps and need spend rails. Not a consumer explainer, and not a vendor brochure. The aim is narrow: the system you are actually integrating, the decision that dominates architecture, and the path from first webhook to a card you can operate.

Companion: How to start a neobank on Solana.

Click to zoom

The problem is not plastic

Kulipa’s shutdown left apps standing and cards dead. Users experience a broken payment. Engineers should see a dependency failure at the licence layer. If your status page has one green light for “the product,” you will lie to yourself the next time an issuer or program manager disappears.

So the job is not “render a card screen.” The job is to attach your product to a regulated network through a stack you only partly control — and to keep user funds and user trust well-defined when that stack breaks.

Five layers, one breadcrumb trail

Clarity starts with naming the layers. Interpretation is the enemy here; the trail should not fork.

Click to zoom

Your brand and UX sit at L5. Your API, risk policy, and double-entry ledger sit at L4 — this is what you own. L3 is the program manager (lifecycle APIs, authorization webhooks). L2 is the issuer or BIN sponsor on Visa or Mastercard. L1 is the scheme and clearing. Marketing collapses L2–L5 into a logo. Architecture must not.

Once the layers are explicit, operational design follows: split SLOs (app_uptime vs card_auth_success), split status copy, and store an IssuerProgram record (legal entity, jurisdiction, PM id) you can show in-product and swap on re-BIN.

The architectural fork: funding model

Here is the detail that should arrive expected, not as a twist: funding model dominates vendor choice. Three patterns appear in production systems.

Click to zoom

Custodial prepaid. The user funds a program balance. Authorization is a ledger hold. Implementation is straightforward; insolvency and program freezes can strand deposits. Disclosures and legal structure are part of the design, not a later PDF.

Self-custodial pull-at-auth. Keys remain with the user. A successful tap implies a chain movement or a pre-authorized spend limit. When the rail dies, plastic dies; principal need not — if you never held spend float. The constraint is time: scheme authorization budgets are often on the order of one to two seconds end-to-end. Waiting for comfortable Solana finality before approve will over-decline under congestion.

Secured credit. Available spend is a line against collateral (LTV-banded). Authorization checks credit, not only a spot balance. Oracles, liquidation workers, and margin policy become first-class services — the card network is only how the world settles the decision.

Authorization: the reasoned middle

With layers and funding fixed, the hot path is mechanical.

Click to zoom

Provision after KYC: create a card through the PM; persist pm_card_id and last4 only; never log PAN/CVV (issuer PCI SDK or iframe for display). On tap, the PM calls your auth webhook. You verify signature, enforce idempotency on auth_id, run cached risk (limits, velocity, MCC, geo), then apply the funding model.

Click to zoom

On Solana, self-custodial spend typically uses transfer_checked into a settlement or per-auth PDA, or a smart-wallet spend-limit CPI. Teams that survive production choose an explicit mode: optimistic approve with a reaper if the chain leg fails, or pessimistic approve with higher declines. Track both auth_p99_ms and post_auth_chain_fail_rate. Bidirectional maps of auth_id ↔ signature turn support from archaeology into lookup.

Clearing and settlement close the loop: holds capture or release; daily reconciliation compares your ledger, the PM file, and chain balances. Unexplained breaks are a stop-ship for new spend features, not a ticket in a backlog.

What “good” looks like when you ship

You are done with the core design when L4 is boring: KYC gates card create; freeze/replace work from support tools; webhooks are at-least-once safe; recon runs daily; the UI states the issuer’s legal name and jurisdiction; status distinguishes app health from card health; a runbook exists for issuer or PM loss (freeze creates, notify, export, re-BIN).

Issuer archetypes (Rain-class volume platforms, white-label EMI/BIN sponsors, regional PMs, bank BINs, principal members) matter for contracts and geo coverage. They do not replace the rule above: rent L1–L3 until you have evidence to own them; never outsource the ledger or risk decision.

Resources

• How to start a neobank on Solana
• Avici · Backpack
• Industry issuer map thread

Bottom line

A crypto card is a multi-layer payments dependency. The app is not the issuer. Funding model sets the failure semantics. Authorization is a latency-bound API with an optional chain subplot. Build L4 as an event-driven system with reconciliation — then the plastic is just the interface the outside world already understands.