Updated April 2026
Tokenisation
The replacement of a real card number with a unique digital token for mobile payments (Apple Pay, Google Pay, Samsung Pay), reducing fraud liability and preventing skimmer compromise.
Tokenisation replaces a cardholder's actual card number (Primary Account Number, PAN) with a unique digital token for payment transactions. When you add a credit or debit card to Apple Pay, Google Pay, or Samsung Pay, the device generates a Device Account Number (DAN, also called a token) that is stored on the device's Secure Element chip. The actual card number is never transmitted to the merchant.
How it works: When you tap to pay at a terminal, the device sends the token plus a dynamic cryptogram (a one-time code generated for that specific transaction). The payment network (Visa, Mastercard) matches the token to your real card number and processes the transaction. The merchant receives only the token and cryptogram, not your actual card number.
Fraud implications for consumers:
1. Even if a merchant's systems are breached, the stored token is useless to fraudsters because it is device-and-transaction specific. Your real card number cannot be recovered from a token.
2. Liability for tokenised payments: Under Visa and Mastercard network rules, tokenised payments (via Apple Pay, Google Pay) are treated as card-present transactions with full zero-liability network coverage. If a tokenised payment is somehow compromised, liability rules are at least as protective as physical card use.
3. Credit vs debit tokenised payments: The underlying liability rules remain those of the card type: a credit card token carries Reg Z protections; a debit card token carries Reg E protections. Tokenisation improves security but does not change the underlying dispute rights.
Samsung Pay uses a similar tokenisation mechanism but historically also used Magnetic Secure Transmission (MST) for older terminals that cannot read NFC (near-field communication). MST-based payments do not go through the same token path and are being phased out as NFC adoption increases.
Note: Some businesses (primarily small merchants) do not accept NFC/contactless payments. In those cases, tokenisation is unavailable, and physical card use (or chip+PIN for debit) is the only option.
Credit vs Debit: how Tokenisation differs
Tokenisation (Apple Pay, Google Pay) improves security equally for credit and debit cards by eliminating PAN transmission to merchants. However, the underlying liability framework remains card-type-specific: credit tokens carry Reg Z protections; debit tokens carry Reg E protections. Tokenisation reduces fraud at the merchant-breach level but does not change the dispute rights that apply when fraud occurs at other points in the transaction.
Related guides
Related glossary terms
Regulation Z
The Federal Reserve / CFPB rule implementing the Truth in Lending Act (TILA) that governs credit card billing disputes and fraud liability.
Regulation E
The CFPB rule implementing the Electronic Fund Transfer Act (EFTA) that governs debit card fraud liability and EFT error disputes.
Chargeback
An issuer-mediated dispute process that reverses a charge back to the merchant, funded through the card network's dispute resolution system.
Dispute
A consumer's formal claim against a charge on a credit or debit card, triggering the issuer's investigation and potential reversal under Regulation Z (credit) or Regulation E (debit).
Verified April 2026 against eCFR.gov and CFPB regulation pages. Not legal advice. Return to glossary →