Disclosure: I work on Sparq, which issues crypto-funded virtual cards. The mechanics below apply to every card.
A card number is a long-lived, unscoped bearer credential replicated across every merchant you've ever used. Tokenization is the fix, and it's a cleaner one than most people realise — worth understanding as a credential design problem rather than a convenience feature.
What changes, structurally
Physical card:
PAN (static, lifetime) + CVV (static, printed)
→ stored in merchant DB
→ breach = fully reusable credential
Tokenized:
token (device-scoped) + dynamic code (per-transaction)
→ stored in merchant DB
→ breach = expired credential, unusable
The PAN is never transmitted to the merchant and never enters their database. A token stands in for it.
On iOS the token lives in the Secure Element — dedicated certified hardware for storing payment credentials and executing crypto operations, physically isolated from the application processor.
The dynamic code is the actual mechanism
Storage location is a nice detail. The load-bearing change is that the merchant receives a security code that changes per transaction.
Static CVV: every merchant who ever processed the card has seen the same value. Any one of them can leak it and it stays valid.
Dynamic code: expired before it could be replayed.
So a breached merchant database containing tokenized transaction records yields credentials that cannot initiate a second transaction. Which is why breached PAN data has a resale market and tokenized transaction data doesn't.
In credential terms: tokenization converts a long-lived bearer credential into a device-scoped one with per-transaction TTL. Same reasoning that makes short-lived tokens preferable to long-lived API keys, applied to payments.
Provisioning failure modes
Provisioning isn't guaranteed. Consistent causes:
Issuer-side tokenization failure — not resolvable device-side
International transactions disabled on the card — check first, most common cause of payment problems generally
Stale wallet tokens after card reissue — remove and re-add usually clears
Temporary authorisation holds locking balance
Issuer lacks clean virtual card provisioning — physical works, virtual doesn't
That last one is the interesting product failure. Virtual cards exist so you can spend before plastic ships. An issuer that provisions physical cards but handles virtual badly has shipped a card number you have to type into forms — reintroducing exactly the PAN exposure tokenization removes.
Retry loops resolve none of these and extend some.
Also worth tracking if you build on card APIs: Google is deprecating the standard Google Pay push provisioning endpoint at the end of 2026, with migration to a unified endpoint required before then. Push provisioning also requires the TapAndPay SDK, a configured wallet on-device, and device binding with a verified mobile number for SCA flows.
Threat model boundaries
"I use Apple Pay" gets treated as a security posture. It isn't one.
In scope: merchant database breaches, card-not-present replay with stolen transaction records, physical skimming.
Out of scope:
Account takeover. Compromise the issuing account and token count is meaningless. Account-level auth is the upstream control.
The funding leg on crypto cards. Blockchain transaction, full finality. Wrong address or network → unrecoverable. No Secure Element helps.
Authorised push payment fraud. If the legitimate user authorises it, tokenization is structurally irrelevant.
Tokenization scopes the credential. It doesn't scope the account.
Where Sparq sits
Virtual cards with no KYC — no document upload, no verification queue — provisioning to Apple Pay and Google Pay.
The narrow claim worth making: for most crypto cards, time-to-first-transaction is gated by verification, not issuance. Virtual numbers generate instantly nearly everywhere; the queue in front of them is the delay. Removing it shortens the path, and that's the whole claim.
Funded from BTC/ETH/USDT over TRC20, BEP20, ERC20. Debit BINs across multiple countries, 3DS and recurring billing supported, non-custodial, PCI DSS, Visa and Mastercard.
Anyone dealt with the Google push provisioning migration yet? Curious how much of the unified endpoint change is mechanical versus requiring flow rework.
Top comments (0)