Card Issuing · Use case
Launch a branded debit or credit card programme
Short answer
Your brand goes on the front; the issuer's BIN, licence and processing sit behind it. Decide the card type first: debit needs an account to draw from, usually via Banking-as-a-Service, and credit needs a lending licence or a credit partner.
What this use case is
A consumer or business card programme under your brand, used for everyday spending online, in store and in mobile wallets.
Who builds this
What your customer sees
- 1Orders a card in the app
- 2Gets a virtual card instantly
- 3Adds it to a mobile wallet
- 4Receives the physical card
- 5Spends and sees real-time notifications
- 6Freezes or unfreezes in the app
How Card Issuing solves it
Card created through the API on the sponsor's BIN
Card created through the API on the sponsor's BIN
Linked to its funding source
account, prepaid balance or credit line
A merchant's authorisation request arrives through the scheme
A merchant's authorisation request arrives through the scheme
The processor checks balance and controls, or asks your system in real time
The processor checks balance and controls, or asks your system in real time
Approve or decline returned within the scheme's time limit
Approve or decline returned within the scheme's time limit
Clearing and settlement update the balance; the statement follows
Clearing and settlement update the balance; the statement follows
Want to have
- BIN sponsorship in your markets
- Virtual and physical cards
- Tokenisation for mobile wallets
- 3-D Secure
- Spend controls
- Real-time notifications
- Dispute tooling
- Support with card design approval
Optional
- Premium materials
- Instant issuance
- Multi-currency spending
Design decisions
Card type
funding setup and regulatory basis differ for each
Consumer or commercial
eligibility and interchange economics
Authorisation
simplicity versus control and latency responsibility
What to put in your RFP
Programme
- card type, consumer or commercial, markets, schemes
Cards
- virtual, physical, materials, fulfilment countries
Features
- tokenisation, 3-D Secure, controls, notifications
Operations
- disputes, fraud, support split
Economics
- fees, interchange share, minimums
Exit
- BIN portability, migration support
How to evaluate providers for this use case
- 1Live programmes in your markets
- 2Wallet readiness at launch
- 3Design approval support
- 4Physical card lead times
- 5Interchange share transparency
Pitfalls
- Underestimating design approval and card production time
- Launching a credit card without a licence or credit partner
- Treating disputes and support as an afterthought
What providers will ask you
- Card type and markets
- Projected active cards and spend
- Funding source
- Launch plan
Other Finlane categories that cover parts of this
This use case is solved mainly with Card Issuing. These categories cover specific parts of it and can be tendered alongside it.
Frequently asked questions
Questions for this use case are covered in the category guide.
Other Card Issuing use cases
Generate one-off or employee-linked virtual cards with granular spend controls, real-time authorization webhooks and category restrictions.
Add Apple Pay and Google PayTokenize your cards so customers can add them to mobile wallets instantly at issuance — with in-app provisioning if needed.
Power a spend-management or corporate card productGive companies a card layer on top of their accounts, with approval flows, receipt capture hooks, and accounting exports.
Roll out cards across multiple regionsCompare issuers by geographic coverage (EU, UK, US, LATAM, APAC) and pick a partner that can grow with your card program.
Enable rewards, cashback or credit lines on cardLayer loyalty mechanics or a small credit facility on top of the card program — via the issuer or a partner ecosystem.