Quick answer When a card is added to Apple Pay or Google Pay, the wallet stores a token rather than the card number, and the merchant receives a dynamic security code that changes with every
When a card is added to Apple Pay or Google Pay, the wallet stores a token rather than the card number, and the merchant receives a dynamic security code that changes with every transaction. A breached merchant database therefore yields tokens that cannot be reused, unlike stored card numbers which retain full value. Provisioning failures are usually caused by issuer-side tokenization problems, disabled international settings, or stale tokens from a previous card version — not by the wallet itself.
Apple Pay and Google Pay do not store cryptocurrency, and they do not store card numbers. They store a tokenized representation of the card and forward payment requests to the card issuer, which verifies the balance and approves or declines the transaction.
The primary account number — the 16-digit number printed on the card — is never transmitted to the merchant and never stored in the merchant's database. A separate token stands in for it.
The storage location differs between platforms. Apple's model relies on a Secure Element: a dedicated certified chip designed specifically to store payment credentials and execute cryptographic operations, physically isolated from the rest of the device.
The most consequential difference is not where the token is stored but what the merchant receives at the point of transaction.
A physical card presents a static three-digit CVV, printed on the card and unchanged for its lifetime. A tokenized transaction presents a dynamic security code that changes for every single transaction.
The practical consequence is significant. When a merchant database is breached — which happens routinely across retail, hospitality, and travel — the transaction records containing tokens are not reusable. The dynamic code has already expired, and the token cannot initiate a second transaction.
A stored card number under the same circumstances retains its full value to whoever obtains it, which is why breached card data has an established resale market and tokenized transaction data does not.
Adding a card to a mobile wallet is not guaranteed to succeed. The recurring causes are consistent across issuers:
CauseSignalResolutionTokenization failure at issuerProvisioning fails immediately for all walletsContact issuer; not resolvable device-sideInternational transactions disabledCard functions domestically onlyEnable in banking or card appStale wallet tokensCard was reissued or changed; old token persistsRemove card from wallet, re-addTemporary authorisation holdsPortion of balance lockedWait for hold releaseIssuer lacks virtual card provisioning supportPhysical card provisions, virtual does notProvider-dependent
The final row deserves attention. Several issuers support wallet provisioning for physical cards while handling virtual cards poorly — which undermines the primary advantage of a virtual card, namely spending before plastic arrives.
Repeated retry attempts do not resolve any of these causes and can extend temporary blocks.
Tokenization addresses a specific threat category and should not be treated as comprehensive security.
Account takeover. If the account issuing the card is compromised, the number of tokens provisioned is immaterial. Account-level authentication is the controlling factor.
The funding transaction. For crypto-funded cards, topping up is a blockchain transaction with full finality. An incorrect address produces an unrecoverable loss regardless of how the card is subsequently used.
Authorised push payment fraud. Where a legitimate user is socially engineered into making a payment, tokenization is structurally irrelevant.
Tokenization protects the transaction. It does not protect the account or the funding leg.
Virtual cards generally provision faster than physical cards and allow spending before plastic ships — provided the issuer supports clean virtual provisioning.
The constraint for most crypto cards is not issuance speed but verification. Most providers issue a virtual number instantly after KYC, meaning the verification queue rather than the issuance process determines when a user can actually spend.
Sparq issues virtual cards without KYC — no document upload and no verification queue — with Apple Pay and Google Pay support. Cards are funded from BTC, ETH, and USDT with top-ups over TRC20, BEP20, and ERC20, issued on debit BINs across multiple countries with 3-D Secure and recurring billing supported, non-custodial and PCI DSS compliant on Visa and Mastercard rails.
Does Apple Pay or Google Pay store my cryptocurrency?No. Mobile wallets store a tokenized card representation and forward payment requests to the issuer. The crypto balance and conversion remain with the card provider.
Is paying by phone genuinely safer than using the physical card?For the specific risk of merchant database breaches, yes. The dynamic security code means stolen transaction records cannot be reused. Other risk categories are unaffected.
Why did my card fail to add to my wallet?Most commonly a tokenization failure at the issuer, disabled international transactions, or a stale token from a previous version of the card. Removing and re-adding resolves the third case.
Can I use a virtual card in physical stores?Yes, where the issuer supports provisioning to Apple Pay or Google Pay. The wallet handles contactless payment identically to a physical card.
Do mobile wallet transactions cost more?No. Payment method does not alter fee structure — fees attach to the card, not to how the transaction is initiated.
