The Unit Economics of Crypto Cards: Why Interchange Isn't Enough (And How to Run a Profitable Operation)

Every crypto card pitch starts the same way: interchange. Every swipe earns a fee, so more cards and more spend volume should mean more revenue. That's directionally true and functionally incomplete. Interchange is a revenue line, not profit, and the number that actually decides whether a program survives is contribution margin per active card, what's left after infrastructure, transaction, and risk costs come out of that revenue. This piece breaks down where that margin leaks, and builds toward a framework for calculating break-even transaction volume before choosing full BaaS, hybrid, or in-house infrastructure.

Key takeaway

• Interchange economics are shared across the issuing stack through commercial agreements, not split evenly four ways. What actually determines profitability is the contribution margin left after infrastructure, transaction, and risk costs.
• A complete unit economics view has four buckets, revenue, variable costs, infrastructure, and customer economics, not just a handful of standalone "money pits."
• Contribution margin per active card matters before LTV/CAC does. If that number is negative, no acquisition math fixes it.
• Which operating model, full BaaS, hybrid, or in-house, is cheapest changes with volume, and the crossover point is program-specific, not a fixed card count.

1. Where Interchange Actually Goes

Interchange is the fee a merchant's acquiring bank pays to the card issuer on every transaction. In a crypto card program, the issuer role is usually held by a BIN sponsor bank, and the program manager's revenue comes from a commercial agreement with that sponsor, a negotiated share of interchange, not a fee that gets divided evenly among a fixed set of parties.

The interchange economics are shared across the issuing stack, while network, sponsor, processor, and infrastructure costs come out of the program's economics separately.

Four parties typically sit in that stack. The card network (Visa or Mastercard) routes the transaction and carries authorization messages between the acquiring and issuing sides, and charges a scheme or assessment fee. The BIN sponsor holds the banking license, bears settlement and compliance risk, and typically charges a setup fee, a per-transaction fee, and takes a negotiated share of interchange, often against posted collateral.

The issuer processor runs the authorization and clearing technology, making the actual approve-or-decline decision on the issuer's behalf, and charges its own per-transaction fee. And the program manager, the entity running the actual product, is responsible for cardholder support and fraud monitoring, and, in a crypto card program, may also be responsible for the wallet and node infrastructure behind the transaction flow, covered in more depth in how a crypto debit card's authorization and settlement architecture actually works.

In the US, Regulation II caps interchange for covered debit-card issuers, those with more than $10 billion in assets, at $0.21 plus 5 basis points of the transaction value, with an additional cent possible as a fraud-prevention adjustment for eligible issuers. Issuers below that threshold are exempt. That makes issuer selection an important unit-economics variable for US debit programs, though the actual economics depend heavily on product structure, debit, prepaid, or credit, and the specific commercial agreement in place, not on a single universal rate.

2. The Hidden Cost Stack

The interchange picture above is the easy part to model. What most launch spreadsheets miss is the full cost stack sitting underneath it. A complete unit economics view has four buckets.

Revenue. Interchange share, FX or conversion revenue, card fees, subscription fees, and any other monetization layered on top of the card itself.

Variable costs. BIN sponsor and issuer share, processor fees, network fees, crypto conversion and liquidity costs, rewards, fraud and chargebacks, KYC/AML cost per user, and card production plus shipping.

Infrastructure. RPC and node access, custody and MPC signing infrastructure, gas, reconciliation, monitoring, and redundancy.

Customer economics. CAC, activation rate, active cards, spend per user, and retention.

Most programs model revenue and the first layer of variable costs reasonably well. Infrastructure and customer economics are where the real leakage tends to hide, which is worth walking through in more detail.

3. The Four Biggest Margin Leaks

RPC and node maintenance. A multi-chain card program needs live, reliable node access to every chain it supports, TRON, Ethereum, BNB, Solana, Polygon, and often more. Chainstack's published pricing formula puts a managed Ethereum full node at roughly $1,279 a month (a Reth-plus-Prysm setup with around 2TB of steady-state storage), before adding redundancy, multi-region deployment, or archive storage, each of which adds cost on top. A meaningful set of other protocols come in under $1,000 a month on the same provider's pricing. Multiply that across five or more chains with redundancy for uptime, and a program is carrying real fixed infrastructure cost every month before a single card is issued.

Manual rebalancing gas fees. Keeping spend wallets funded across chains means sweeping deposits and rebalancing hot wallets, and gas adds up fast at volume. For illustration, not as a typical card-program benchmark, one example from institutional custody operations: sweeping 5,000 deposit addresses a day at an average of $0.20 per transaction runs close to $30,000 a month on sweeping alone, before withdrawals, rebalancing, or cross-chain settlement are factored in. The gap between chains makes manual processes riskier: congested Ethereum L1 transactions can run $1 to $20 or more, while Solana and L2s like Base or Arbitrum cost a fraction of a cent to a few cents. A program that rebalances manually instead of batching and automating pays the expensive rate far more often than it needs to, a problem automated reconciliation infrastructure is built to solve.

POS declines. A declined authorization produces no interchange revenue, regardless of the underlying cause. For crypto-funded cards specifically, the authorization path often depends on a real-time crypto-to-fiat conversion step: if the conversion or liquidity path fails, or the asset isn't eligible or available for conversion at that moment, the transaction can decline even when the user's total crypto balance is sufficient. Not every crypto card is architected this way, but where it applies, it adds a decline mode that a standard fiat debit card never has to solve for, and every decline is a transaction that never earns interchange, plus a support ticket, plus a cardholder who now doubts the product works.

Inactive and never-activated users. Inactive and never-activated users create a large hidden acquisition cost in any product where CAC is paid before a user ever transacts, and the program may incur that cost twice: once in acquisition spend, and potentially again through per-card issuance or other account-level fees charged under its sponsor agreement. One third-party 2025 benchmark puts fintech activation at around 5%, but definitions vary widely across products, and separate research on new checking accounts found roughly 34% going inactive within their first year. Neither number is a crypto-card-specific benchmark, but they illustrate a gap worth measuring directly in your own cohort data rather than assuming it away.

These four leakage points are usually not visible in a simple interchange-revenue view. That's exactly why they're dangerous: a program manager who budgets only against gross interchange, and not against what's actually left after this cost stack, is running on a number that was never real.

4. Don't Calculate LTV First. Calculate Contribution Margin.

A card program is a transactional business, not a subscription business, and that distinction matters more than it first appears. In SaaS, the standard heuristic is a 3:1 LTV/CAC ratio, a benchmark that traces back to investor David Skok's work at Matrix Partners and sits at a 3.2:1 median for B2B SaaS in 2026. The 3:1 ratio is a commonly cited SaaS heuristic, but the appropriate thresholds depend on the business model, retention pattern, and margin structure.

That heuristic is a useful directional benchmark, but it is not a crypto-card standard, and importing it wholesale skips a step that matters more for a transactional product: contribution margin per active card. If a card loses money on every dollar it processes after variable and infrastructure costs, no lifetime-value multiple fixes that. More active cards just means losing money faster. Card programs should prioritize contribution margin per active card, CAC payback, and cohort retention, and treat LTV/CAC as a secondary sanity check, not the primary metric.

5. The Break-Even Calculator

Contribution margin, not gross interchange, is the number a program should be solving for. Two formulas do the work:

Contribution margin per $1 of card spend = interchange revenue share − sponsor and processor fees − network and transaction costs − crypto conversion and liquidity costs − rewards − fraud and chargeback losses − variable infrastructure cost per transaction

Break-even TPV (total processing volume) = Fixed monthly costs ÷ contribution margin per $1 of card spend

One accounting note worth getting right: interchange revenue share above should be the program's actual net receipt under its commercial agreement. If sponsor and processor fees are already netted out of that share, don't subtract them again separately; if you're starting from a gross contractual interchange rate instead, subtract each fee once.

Fixed or step-fixed monthly costs are the infrastructure and overhead a program carries regardless of, or in broad bands independent of, monthly transaction volume: node and custody infrastructure, monitoring, a baseline compliance and support team. Once contribution margin per active card is known, the same logic gives a break-even card count:

Break-even active cards = Fixed monthly costs ÷ contribution margin per active card per month

The table below is a starting worksheet. Fill it in with your own numbers, not assumed ones, since every input varies by market, sponsor agreement, and chain mix.

From those inputs, calculate four numbers that tell you more about whether the program works than a headline interchange rate ever will: contribution margin per active card per month, break-even TPV, break-even active card count, and CAC payback period in months.

Worked example (illustrative numbers, not data from any real program): if a program nets $0.006 of contribution margin per $1 of card spend after every cost in the formula above, and carries $60,000 a month in fixed and step-fixed costs, break-even TPV is $60,000 ÷ $0.006, or $10,000,000 in monthly processing volume. At $500 in average monthly spend per active card, that's $500 × $0.006 = $3 of contribution per card per month, so break-even active cards is $60,000 ÷ $3, or 20,000 active cards. Ten million dollars a month in volume looks like a thriving program on a dashboard. Whether it actually is depends entirely on that $0.006, which is the whole reason to run this math before reading volume as a proxy for profitability.

6. BaaS vs. Hybrid vs. In-House: A Volume-Based Decision

Which layer of the cost stack a program owns changes which operating model actually makes economic sense, and that answer isn't fixed. It moves with volume.

Rain, a Visa principal member with a vertically integrated stablecoin issuing stack, is one example of the full-stack end of this spectrum, and it isn't the only one: general-purpose card issuing platforms like Lithic, Highnote, and Marqeta can occupy adjacent parts of the stack, particularly when paired with separate crypto infrastructure. None of these represent the entire category, and the right vendor depends on the chains, markets, and product structure involved.

At the other end, fully in-house means running your own node infrastructure, your own MPC or multisig wallet stack, and negotiating directly with a BIN sponsor and processor, which is the model most exposed to the four margin leaks in section 3 and the one covered in the self-hosted vs. SaaS wallet infrastructure decision framework. Hybrid infrastructure sits in between: managed wallet and node infrastructure absorbs the multi-chain maintenance burden, while the program keeps card logic, decline handling, and activation flows in-house, the same "your choice on where it runs, same APIs, same security posture" tradeoff laid out in how crypto on-ramps actually work and in Fystack vs. Fireblocks on digital asset custody more broadly. Teams that want to see where their own cost floor actually sits before committing to either can self-host a full custody stack with one command and test it directly.

7. The Architecture That Wins Changes With Volume

The cheapest infrastructure model at low volume is rarely the cheapest at high volume, because fixed costs amortize differently at different scales. As a directional framework, not a universal rule:

• At low volume: BaaS tends to be economically attractive, since avoiding fixed infrastructure costs can outweigh the higher variable fees a vendor charges.
• As volume grows: hybrid infrastructure can become attractive once the savings from owning selected layers outweigh the additional operational cost of running them.
• At sufficiently high volume: in-house infrastructure can become economically attractive once fixed costs are amortized across enough total processing volume.

There's no universal card count where one model overtakes another. The actual crossover point is program-specific and should be calculated from your own commercial agreements and cost structure using the worksheet in section 5, not assumed from a generic volume tier.

FAQ

Don't ask how much interchange your card generates. Ask how much contribution margin remains after the infrastructure required to generate it survives contact with node costs, conversion costs, declines, and inactive users. That's the number that decides whether a program runs profitably, and it's the number the calculator above is built to produce.

If the break-even math points toward owning more of the infrastructure stack as volume grows, here's one way to approach that transition: Fystack builds open-source, self-hosted custody with a policy engine that enforces spend rules before signing, the same stack covered in what an MPC wallet actually does.

About Fystack: Fystack is a self-hosted, open-source custody platform for fintech teams. Its core signing infrastructure, mpcium, is open source on GitHub, and supports TRON, ETH, BNB, Solana, Polygon, and more.

If you are evaluating your custody and compliance infrastructure, the Fystack team would be happy to discuss your requirements and explore the right implementation approach.