Card Issuing · Use case
Add Apple Pay and Google Pay to your cards
Short answer
Tokenisation lets your cards live in mobile wallets. Your issuer or platform connects to the schemes' token services, and your programme is enabled with each wallet. Push provisioning — "Add to Wallet" inside your app — is a separate integration and approval.
What this use case is
Your card stored as a token on a phone or watch, used for contactless and in-app payments without exposing the card number.
Who builds this
What your customer sees
- 1Taps "Add to Apple Wallet" or "Add to Google Wallet" in your app
- 2Confirms
- 3The card appears in the wallet
- 4Pays by phone
- 5Freezing the card in your app also stops the wallet card
How Card Issuing solves it
The customer adds the card manually or from your app
The customer adds the card manually or from your app
The wallet requests a token from the scheme's token service
The wallet requests a token from the scheme's token service
The issuer side checks the request, with a step-up check where needed
The issuer side checks the request, with a step-up check where needed
The token is provisioned to the device
The token is provisioned to the device
Payments use the token instead of the card number
Payments use the token instead of the card number
Lifecycle events — freeze, replace, close — are synced to the token
Lifecycle events — freeze, replace, close — are synced to the token
Want to have
- Scheme token service integration
- Apple Pay and Google Pay enablement for your programme
- Push provisioning support
- Identity step-up methods
- Token lifecycle management
Optional
- Merchant tokens for card-on-file
- Wearables
- Other wallets such as Samsung Wallet
Design decisions
Provisioning
less work versus a far smoother customer experience
Wallets
coverage versus onboarding effort per wallet
Onboarding paperwork
speed versus control
What to put in your RFP
Wallets
- which are live for your BIN and markets
Provisioning
- push provisioning SDKs, approval support
Security
- step-up methods, token lifecycle handling
Timing
- typical enablement steps [TO CONFIRM: ask providers for current timelines]
How to evaluate providers for this use case
- 1Wallets live today in your markets
- 2Push provisioning experience
- 3Lifecycle sync reliability
Pitfalls
- Assuming wallet enablement is immediate
- Push provisioning needing its own approval
- Lifecycle bugs where a frozen card still works in the wallet
What providers will ask you
- Markets
- Wallets needed at launch
- Your app's release 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
Ship a consumer or B2B card program with your brand on the front and the issuer’s BIN, licence and processing behind it.
Issue virtual cards for expense managementGenerate one-off or employee-linked virtual cards with granular spend controls, real-time authorization webhooks and category restrictions.
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.