Launching a Card Programme: A Practical Checklist
Everything to settle before your first real cardholder: funding, branding, integration, support, reconciliation and the questions that appear only after launch.
In short
A card programme fails on operations far more often than on integration. This is the checklist of what to have settled before the first real cardholder — most of which is not code.
The engineering for a card programme is a few days. The things that determine whether it goes well are mostly not engineering, and they are mostly discovered after launch by people who did not plan for them.
This is what to settle first, in the order it tends to matter.
Before you write any code
- Decide what a card is for in your product. One card per user? Per purchase? Per project? This decides your economics and your architecture, and changing it later means migrating real cardholders.
- Know your load distribution. Not the average — the shape. It determines which fee structure suits you and whether issuing or topping up should dominate.
- Decide who may get a card. And what happens when someone should not have one. Both are product decisions, not compliance afterthoughts.
- Work out who answers the support email. Cards generate questions from people who are mid-purchase and unhappy. Nominate someone before that starts.
Funding
- Account activated and a real deposit made — not just planned.
- You have watched the detected and credited notifications arrive, and confirmed the balance matches.
- You know the confirmation wait for the chain you actually use.
- Someone owns topping up the float, with a threshold at which they do it. A programme that runs out of balance declines every issue until somebody notices.
Branding
- Brand name, logo, website, support email and WhatsApp all set — before any real card is issued.
- A test card issued to yourself, and the welcome email read on a phone.
- The logo checked against the dark template for transparency and contrast.
- A card design chosen deliberately rather than defaulted to.
Integration
- Idempotency keys derived from your own domain and stored before the first attempt.
- The provisioning state handled — a card that is issued but not yet usable must not be shown as ready.
- Card ids stored against your own users.
- Fees recorded on your side as components, not just totals.
- Bulk operations queued with bounded concurrency rather than fired in parallel.
- API keys scoped, IP-allowlisted and out of the repository.
Money and books
- Your own ledger. The provider's balance is not your accounting system. Track what you owe users independently.
- A reconciliation job comparing your records against the provider's, that alerts rather than silently correcting.
- A tested failure path. Issue a card that fails and confirm the reservation is released and your ledger agrees.
- A refund story. When a user wants money back off a card, know what you do before someone asks.
Support readiness
This is where new programmes struggle most. Write the answers before launch:
| Question you will be asked | Have an answer ready |
|---|---|
| "My card was declined" | How to check the balance, and the usual reasons |
| "I did not get my card email" | How to resend or show the card in your own UI |
| "Someone asked for my verification code" | A stated policy that you never ask; how to freeze |
| "I want a refund" | Your process, including what you will not do |
| "Can I use it at an ATM?" | No — say it up front, not at first attempt |
| "Why did my deposit not arrive?" | Confirmation waits, and the wrong-network case |
A staged launch
- Yourself. Issue one card, spend on it, complete a 3-D Secure challenge, freeze and unfreeze it.
- Your team. Ten cards to colleagues who will report problems honestly and who you can interrupt.
- A friendly cohort. Fifty real users who know it is new. This is where you learn your real support volume.
- Open it. Only once the previous stage produced no surprises you had to fix at speed.
The temptation is to skip to the last step because the integration works. The integration is not what breaks.
The first week
- Watch the API request log daily. Unexpected IPs, 401 spikes, unexplained issuance.
- Reconcile daily to begin with, then weekly once it is boring.
- Read every support message yourself for the first week, whoever owns the queue afterwards. The pattern in the first fifty tells you what to fix.
- Track your decline rate. A high one usually means loads are too small for what users are trying to buy.
What to review after a month
- Actual load sizes versus your assumption. These are almost never the same, and the difference may change which fee structure suits you.
- Issue versus top-up ratio. If users top up often, a persistent card is cheaper than reissuing.
- Support volume per hundred cardholders. This is your real operating cost and it scales with cardholders, not revenue.
- Whether the economics still favour your model. With a month of real data you can finally answer the sponsored-versus-network question properly, rather than guessing at it.
Frequently asked questions
What should I check before launching a card programme?
Funding and float ownership, branding set before any real card is issued, idempotency and provisioning states handled in the integration, your own ledger and a reconciliation job, and written support answers for the questions cardholders reliably ask.
How should a card programme launch be staged?
Yourself first, then a small internal group, then a friendly cohort of around fifty real users, then open access. The integration is rarely what breaks; support volume and operational gaps are.
What should I monitor in the first week?
The API request log for unexpected IPs and 401 spikes, daily reconciliation between your records and the provider's, every support message, and the decline rate — which usually indicates loads are too small.
Do I need my own ledger if the provider tracks balances?
Yes. The provider's balance is not your accounting system. Track what you owe your users independently and reconcile against the provider regularly.
Issue your first card on ON5
Fund an account with USDT or USDC and issue a branded Visa or Mastercard virtual card. The minimum is $5.
Open the dashboard