> ## Documentation Index > Fetch the complete documentation index at: https://www.bitnob.dev/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Bitnob API requests authenticate with an `X-Auth-Client` API key header against https://api.bitnob.com. > Always use the sandbox environment for testing. Never put live API keys in sample code. > Money amounts are integers in the smallest unit of the currency (satoshis for BTC, cents for fiat). Never use floats. > Every state-changing request takes a client-supplied `reference` and must be treated as idempotent on retry. > Quotes expire. Re-quote rather than reusing a stale quote id. # Module 14: Card-based product use cases and strategy > Card-powered product patterns, the strategy behind each, and how they make money. ## Learning objectives * Discover common and emerging use cases for virtual cards * Understand the strategic rationale behind card-powered products * Learn how to match lifecycle, limits, and UX to each use case * See real-world product patterns and monetization strategies * Design your own virtual card product with clarity and purpose ## Why card-Based products matter A virtual card is not just infrastructure. It’s a programmable spending primitive. When used properly, cards unlock: * Global spend access for users in restricted regions * Budget enforcement for teams and families * Embedded finance for platforms and marketplaces * Invisible financial workflows that just work in the background Your job as a builder is to turn that primitive into a cohesive product. ## Common card use cases ### 1. Freelancer and contractor payouts Give each user a USD card instead of a bank payout. * Fund directly from USDT or fiat balance * Spend globally without local banking friction * Set monthly, weekly, or per-project limits * Let users withdraw or top-up as needed **Why it works:** Speed, accessibility, and reduced cross-border transfer costs. ### 2. Subscription control for consumers Let users create disposable cards for Netflix, Spotify, Notion, etc. * Issue a new card per service * Show spend summary per card * Let users freeze or terminate to cancel subscription * Set per-month or per-service limits **Why it works:** Users hate surprise charges. You give them control without needing support tickets. ### 3. Marketing and ad spend cards for teams Each team or channel gets a dedicated card for ads, influencer campaigns, or growth experiments. * Name cards by campaign (e.g., "March TikTok") * Set fixed budget per card * Track spend by merchant * Pause/freeze cards when campaigns end **Why it works:** Enables real-time tracking and prevents overspending. ### 4. Corporate expense cards Give employees virtual cards with limits for remote work, tools, travel. * Set per-person limits * View spend across categories * Require justification for top-ups * Auto-freeze cards after inactivity **Why it works:** Replaces manual reimbursements and centralized spend bottlenecks. ### 5. Savings to spending transitions Let users save in stablecoins or local currency and convert savings to a card when ready. * Target-based issuance (“Issue card once I’ve saved \$200”) * Convert savings to spendable USD on demand * Add optional maturity rules (freeze until date) **Why it works:** Builds a bridge from disciplined saving to intentional spending. ### 6. Event-driven cards (e.g., gifting, promotions) Create cards tied to a specific event or milestone. * Reward a user with a preloaded card * Expire card after 30 days * Issue one-time-use cards for contests, referral bonuses, etc. **Why it works:** Quick issuance, budget control, great user delight. ## Product architecture matching Each use case benefits from specific configurations: | Use Case | Lifecycle | Top-up Logic | Spend Limits | Ux Priority | | - | - | - | - | - | | Subscription Control | Active → Frozen → Terminated | User-triggered | Monthly cap | Transaction transparency | | Freelancers | Active | System-triggered | Per-project | Balance visibility | | Teams | Active | Admin-triggered | Daily/weekly | Control + monitoring | | Promotions | Active → Auto-Terminate | Preloaded only | Fixed cap | Simplicity | | Savings | Frozen → Active | Goal-triggered | Full balance | Clarity of transition | Use this framework to design each card experience intentionally, not generically. ## Monetization models per use case | Use Case | Monetization Pattern | | - | - | | Freelancers | FX markup, top-up fee | | Subscriptions | Flat monthly card access fee | | Teams | SaaS model based on number of cards or users | | Promotions | Cost absorbed as CAC, card creation cost passed to marketing | | Embedded finance | Platform markups on issuance and usage (B2B2C) | ## Distribution models | Model | Description | | - | - | | Direct to consumer | Wallet or banking app includes card feature | | Platform-based | SaaS platform offers cards as part of core workflow | | Reseller or white-label | You offer card issuance infrastructure to others | | API-first | Partners programmatically issue and manage cards through your backend | Choose your model based on control, regulatory posture, and go-to-market alignment. ## Strategic questions to guide your card product * Who is funding the card, user, business, or platform? * Is the card always visible to the user? Or used silently behind the scenes? * What is the lifecycle pattern, open-ended, per-event, disposable? * What is the desired behavior you're enabling or limiting? * How will your support team handle reversals, declines, and refunds? * Are you building a business around cards or adding cards to an existing system? Your answers define the product’s shape more than the API ever will. ## Recap * Virtual cards can power a wide range of real products, not just payments, but full workflows * Each use case requires different lifecycle design, funding logic, and user interaction * Matching product architecture to real-world needs creates better tools, not just functional features * Monetization should fit the role of the card in your ecosystem: tool, reward, control, or payment layer This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.