Mobile wallet tokenization is a security process where a payment card’s primary account number (PAN) is replaced with a token (a substitute number) when a card is added to a mobile wallet such as Apple Pay or Google Pay. The token can be used for payments, but it does not expose the real card number, reducing fraud risk in EV charging payments and other transactions.
How mobile wallet tokenization works
Tokenization typically happens in two stages: provisioning and payment.
– Provisioning (adding a card): the wallet requests a token from a token service (often via the card network), and the issuer approves it
– The token is stored securely on the device (often in a secure element or secure OS area)
– Payment execution: when paying, the device uses the token plus a one-time cryptographic value (dynamic security code) to authorize the transaction
– The payment network maps the token back to the real card number only inside trusted systems, so merchants and operators never receive the PAN
Why tokenization matters for EV charging
For charge point operators and payment flows, tokenization improves security and conversion:
– Reduces exposure of card data in apps, web checkouts, and terminals
– Helps lower fraud and limits the impact of data breaches
– Supports smoother user experience with stored payment credentials
– Enables fast contactless payments (tap-to-pay) and in-app wallet checkouts
– Simplifies compliance scope by avoiding direct handling of raw card numbers (while PCI DSS obligations may still apply depending on architecture)
Tokenization vs encryption
These are often confused, but they solve different problems:
– Tokenization replaces sensitive data (PAN) with a surrogate token that has no usable value if stolen
– Encryption scrambles data so it can be decrypted later with a key
In mobile wallets, both are used: tokenization protects the PAN, while encryption and cryptography protect the transaction in transit.
Operational considerations for CPOs and payment flows
When implementing mobile wallet payments and tokenization, operators should plan for:
– PSP support for wallet tokenized transactions and network tokenization
– Clear handling of pre-authorization holds and final capture (common in EV charging)
– Refund logic that correctly references tokenized payment identifiers
– Strong session linkage between payment authorization and charger start via CPMS
– Monitoring for failed starts and “paid-but-not-charging” cases to protect customer trust
Common limitations and issues
– Token provisioning can fail due to issuer rules, device security settings, or unsupported regions
– Wallet tokens are device-specific, so switching phones requires re-provisioning
– Disputes and chargebacks still occur; tokenization reduces fraud but does not eliminate it
– Offline or poor connectivity can disrupt QR/web-based wallet payments even if tokenization is enabled
Related glossary terms
Mobile wallet payments
Contactless payment
Payment service provider (PSP)
PCI DSS
Tokenization
Encryption
Pre-authorization
CPMS
OCPP
Ad-hoc payment