When a card is added to Apple Pay or Google Pay, the handset does not keep the 16-digit card number. Apple's support documentation describes a Device Account Number assigned during setup, encrypted and stored in the phone's Secure Element, with the physical card number held nowhere on the device (Apple, 2025). That assignment — provisioning — is a five-party handshake.
Nuv Media publishes information, not financial advice. This explainer walks through provisioning from two sides: the issuing bank that must approve the request and the device that ends up holding the credential.
What happens when a customer taps add card?
The wallet gathers the card data first — manual entry, a camera capture, or a push from the issuer's own banking app — and then asks a token service provider to mint a token for that account. The token service provider, typically Visa Token Service or Mastercard Digital Enablement Service, operates the token vault under the EMVCo Payment Tokenisation Specification first published in March 2014 (EMVCo, 2014). No token is issued until the issuer approves the request, which is why provisioning can fail even when the card data is typed correctly.
The sequence matters for fraud teams because every step leaves a decision point. The wallet identifies itself as a token requestor with a registered ID, submits the account details, and waits. The token service provider forwards the request to the issuer for validation, and only after issuer approval does the network generate a format-preserving token — a number that looks like a PAN to downstream systems but maps to the real account only inside the vault.
Two entry paths behave differently at this step. Manual entry puts the burden of identity proofing entirely on the issuer's step-up checks. Push provisioning — starting inside the issuer's authenticated app — arrives pre-vetted, because the customer already logged in with the bank's own credentials, which is why issuers route digital-first cardholders through in-app wallet buttons.
How does the issuer decide the requester is genuine?
Issuers validate provisioning requests with layered checks: a one-time passcode to the phone number or email on file, a look at device and behavioral signals, or a handoff into the banking app for authentication. An issuer can decline the tokenization outright, and network rules treat that decline as a routine risk control, not an adverse action — the underlying account stays open.
The verification step exists because provisioning is a credential-issuance event, not a payment. A criminal who provisions a stolen card into his own phone gains a working credential at every contactless terminal, so issuers apply the same identity discipline they would use for a card reissue. Apple requires a device passcode before any card can be added, which gives issuers a baseline device-bound factor on top of their own checks (Apple, 2025).
Google's wallet follows the same pattern with different plumbing. Google Pay help documentation describes a virtual account number stored on the device's secure hardware, used for payments in place of the real card number, with tokens supplied through the same network token services (Google, 2025).
Where does the token actually live?
On iPhones, the token sits in the Secure Element, a certified tamper-resistant chip certified to industry security standards; Apple says card numbers are neither stored on the device nor on Apple servers (Apple, 2025). On Android devices, the credential lives in protected hardware such as a secure element or trusted execution environment, depending on what the handset maker fitted.
Storage location is what makes the token device-bound. The wallet also gates use of the credential behind the device's biometric or passcode check — Face ID, Touch ID, or the Android equivalent — so possession of the phone alone is not enough to pay. Each authorization generates a dynamic transaction cryptogram from the secure hardware, which means an intercepted token has limited replay value compared with a printed card number.
For issuer operations, the practical consequence is an inventory problem. One cardholder can hold tokens across a phone, a watch, a tablet and several merchant profiles, each with its own state. Token dashboards inside Visa and Mastercard services let issuers see and manage every token issued against a PAN — the foundation for the lifecycle events that follow.
What happens when a phone is lost or replaced?
Tokens have a lifecycle: active, suspended, resumed or deleted. When a customer reports a lost phone, the issuer suspends or deletes the device token through the token service provider while the physical card keeps working; when she restores a backup onto a new handset, fresh provisioning creates a new token rather than copying the old credential. Network token lifecycle messages carry these state changes so merchants and processors stop charging a dead credential.
Suspension is also routine. A customer who temporarily cannot verify with biometrics, a handset in repair, or a fraud watchlist hit can each put a token on hold without closing the account. The EMVCo framework defines these states so that wallets, networks and issuers stay in sync as devices change hands, break, or get retired (EMVCo, 2014).
Issuers that manage this inventory well report fewer false declines after device upgrades, because authorizations stop hitting a token that no longer exists. The rule of thumb in card operations: treat every device like a virtual card issued, and retire it as deliberately as a plastic reissue.
Who controls access to provisioning?
Access rules have drawn regulators on two continents. The U.S. Department of Justice sued Apple in March 2024, alleging the company excluded rival wallets from the iPhone's NFC chip and charged card issuers fees of up to 0.15 percent of Apple Pay transaction value for token provisioning; the allegations remain contested litigation (DOJ, 2024). In the European Union, the European Commission made Apple's commitments to open iPhone NFC access to competing wallets legally binding in July 2024 (European Commission, 2024).
For issuers, the take-away is operational rather than legal: provisioning cost, wallet availability and token portability are set by the networks and handset platforms, and terms can shift under regulatory pressure. Issuers that instrument their token inventories — knowing exactly which devices hold live credentials — are positioned to respond when those terms move.
For more context, read How Open Banking Consent Flows Secure Customer Data Access.
For more context, read agentic commerce payments.
For more context, read How Machine Learning Models Score Payment Fraud in Real Time.
