Skip to main content
This is the path from nothing to a working virtual card product. Each stage names the decision you have to make, the pages that show you how, and the thing you should have finished before moving on. It assumes you are building on Bitnob virtual cards: prepaid USD Visa cards, funded from your Bitnob balance.

​
Who this is for

  • Founders building a fintech product where card spend is the core action
  • Product managers adding cards to an existing wallet or payroll product
  • Developers standing up an MVP or a proof of concept
  • Agencies enabling card services on behalf of clients

​
Stage 1: Decide what the card is for

Before any code, answer one question: what does the card let your user do that they cannot do today? The answer determines everything downstream, including whether the economics work at all. Common shapes that work:
  • Ad spend. Agencies and marketers who need cards per campaign or per client.
  • Freelancer and contractor payout. Recipients who want to spend rather than withdraw.
  • Subscriptions. Users in markets where local cards are declined by international merchants.
  • Corporate and team spend. One card per employee, per project, or per vendor.
Write down the single transaction you expect the user to make in their first session. If you cannot describe it in one sentence, the product is not scoped yet.

​
Stage 2: Learn the primitives

Cards carry vocabulary that leaks into every later decision. Cover these before you design flows: If you want the long-form version, the card issuing course covers the same ground across 23 modules.

​
Stage 3: Model the unit economics

Do this third, not last. The fee schedule decides whether your pricing can work, and it is the stage most teams skip. The published fees are on Fees and decline rules. The ones that shape a business model most: Build a sheet with one row per user cohort and these columns: cards issued, average load, loads per month, share of spend that is cross-border, and expected chargebacks. Then check three things:
  1. Does a single card ever pay back its $1.00 creation fee? If users issue cards they never fund, your acquisition cost is higher than it looks.
  2. Where does your revenue come from? The usual options are a markup on funding, an FX spread, a subscription, or interchange-like share. Pick one as primary.
  3. What does one chargeback cost you? At $60 flat, a single dispute can wipe out the margin on many months of ordinary spend. This is a pricing input, not an edge case.
The decline rules have a business consequence, not just a technical one. A second declined authorisation costs $0.75, and by default a third permanently terminates the card. Users who repeatedly attempt payments on an underfunded card will lose it and need a new one at full creation cost. Design your interface to prevent the second decline.

​
Stage 4: Build the integration

Work in sandbox until the whole path runs end to end.
1

Get one card issued

Follow Issue your first card start to finish. It covers credentials, customer creation, and issuance.
2

Fund it and spend from it

Load the card, then confirm the balance moved. See Fund a card.
3

Receive webhooks

Stand up a signed, idempotent handler before you build any interface on top. See Receive card webhooks and the event reference.
4

Handle the lifecycle

Implement freeze, unfreeze, and terminate, and decide which of them your users can trigger themselves.
5

Monitor transactions

Wire up transaction monitoring so support can answer questions without you.
The API v2 Postman collection ships with request signing already wired up, which is the fastest way to explore before writing code.

​
Stage 5: Design onboarding

Card issuance depends on a verified customer, so onboarding is where most conversion is lost. Two rules carry most of the value:
  • Ask for identity information once, at the point it is required, not as a wall before the user has seen the product.
  • Explain why you need each field. Verification requests without context read as data harvesting.
The customer record must be complete before issuance, so validate your side before calling the API rather than surfacing raw API errors to users.

​
Stage 6: Write your operational procedures

You need these before real users, not after your first incident. Each already exists as a playbook:

Support playbook

How to answer a declined transaction, a missing refund, or a frozen card.

Fraud and compliance

Controls, triage, and staying audit-ready.

Treasury and finance ops

Float management, reconciliation, and month-end.

Card fraud course

Fraud patterns and the controls that catch them.
At minimum, write down who is on call, what the refund decision rule is, and who can terminate a card.

​
Stage 7: Go to market

Marketing a card product is mostly about naming the constraint you remove. The marketing playbook covers positioning and channels. One thing worth stating plainly in your own copy: the card is prepaid and denominated in USD. Setting that expectation before signup prevents most early support volume.

​
Pre-launch checklist

Do not take real users until every line is true:
  • A full issue, fund, spend, and terminate cycle works in sandbox.
  • Your webhook handler verifies signatures and is idempotent.
  • Live credentials are server-side only, and rotated away from anything used in testing.
  • Your fee model is written down and reviewed against the published schedule.
  • Support has a written procedure for declines, refunds, and disputes.
  • Someone owns the float and knows how to top it up.
  • Your interface prevents a user from attempting a second declined authorisation.