You tap your phone at a coffee shop, hear the beep, and the charge hits your card. Your real 16-digit card number never appears on the receipt, never leaves your phone’s secure chip, and never gets typed into the merchant’s app. That is tokenization at work, and if you use a crypto card, virtual-card-number feature, or mobile wallet, you rely on it every day.
The word gets thrown around loosely, but “token” actually describes two very different things. One keeps online merchants away from your card number. The other is what makes Apple Pay, Google Pay, and many virtual crypto cards possible.
The two kinds of token you should know
Gateway tokens are issued by a payment gateway, acquirer, or the merchant’s own token vault. When you save a card on an e-commerce site, the merchant does not want to store your real PAN because real card numbers drag its systems into strict PCI DSS compliance scope. Instead, the gateway stores the real PAN in a hardened vault and gives the merchant a token that only works within that merchant-plus-gateway relationship.
That is a clean compliance win, but the benefit mostly stops there. A gateway token is usually locked to that merchant or gateway, does not travel with you, and does not update itself if the underlying card is reissued.
Network tokens are issued at the card-scheme level, with your issuer’s authorization, through services run by Visa, Mastercard, and American Express. This is the machinery behind mobile wallets and many modern virtual-card products. The token is bound to a specific device, merchant, or use case, and it can be refreshed without you doing anything. That is what makes tap-to-pay feel seamless and secure.
How Apple Pay keeps your real number hidden
When you add a card to Apple Pay or Google Pay, your phone becomes a token requestor. It asks the scheme’s Token Service Provider (TSP) to issue a network token for that specific device. The token stored on your phone is called a DPAN (Device PAN), distinct from the FPAN (Funding PAN), which is your real card number.
From that moment on, your real PAN does not live on your phone and is not sent to the merchant. When you tap to pay, the terminal receives the DPAN plus a one-time cryptogram generated by the secure element in your device. The cryptogram is unique to that transaction and cannot be replayed later. Even if someone intercepted the radio signal, the captured data would be useless for a second purchase.
This combination, device-bound token plus dynamic cryptogram, is why a stolen transaction message is not the same as a stolen card number. Our post on what happens inside card authorization walks through the full approval path, and the auth flow demo lets you step through it interactively.
Why this matters for virtual crypto cards
Many crypto card products, especially those that issue instant virtual cards, use the same network-token concepts. The app requests a token tied to the device or to the card’s virtual profile, and the card number you see in the app is not the raw funding instrument behind it. Your real underlying relationship, whether a stablecoin balance, custodial wallet, or issuer account, stays on the provider’s side.
That matters when you are choosing between cards. A virtual card that simply shows a static PAN is different from one that issues a device-bound token with per-transaction cryptography. The former may be convenient, but it lacks the replay resistance and domain restriction that make contactless mobile wallets trustworthy. Our RedotPay vs Bybit Card breakdown looks at how these security models differ in practice among crypto card providers.
Renewals are another place the token type shows up. A network token can survive a card reissue because the TSP remaps it to the new PAN behind the scenes. A gateway token typically cannot. That matters if you keep a card on file for recurring top-ups or subscription billing.
What to watch out for
The biggest trap is assuming that “tokenized” always means “as secure as Apple Pay.” A token is only as strong as the restrictions around it. Ask two questions when you evaluate a product:
- Who issued the token? A gateway token is primarily a compliance tool. A scheme network token brings automatic updates, higher authorization rates, and device-level binding.
- What domain is it bound to, and is there dynamic verification? A static token with no per-transaction cryptogram is closer to a disguised card number than to a mobile-wallet token.
Some products market themselves as fully tokenized but are really using gateway-style vaulting. That may be fine for checkout convenience, but it does not deliver the security model that makes tap-to-pay trustworthy. Our payment auth wiki covers the technical labels you will see in marketing materials, so you can read past the buzzwords.
Takeaways
- Tokenization is not one thing. Gateway tokens replace your PAN in merchant systems. Network tokens replace it at the scheme level and can be bound to a device or use case.
- Mobile wallets use network tokens. Your phone stores a DPAN, not your real PAN, and each transaction carries a fresh cryptogram that cannot be reused.
- Virtual crypto cards borrow the same idea. The card number in your app may be a token, but check whether it is device-bound and dynamically verified, or simply a static surrogate.
- Renewals depend on the token type. Network tokens can survive card reissues; gateway tokens usually cannot. That matters for recurring billing and stored-card top-ups.
Next time you tap your phone or open a crypto card app, you are not just paying. You are proving that the transaction came from your enrolled device, without ever exposing the funding number behind it.