Device Tokens and Mobile Wallets

Device tokens are the form of tokenization that powers mobile wallets such as Apple Pay and Google Pay. When a customer adds a card to a wallet, the wallet does not store the real card number on the phone. Instead it requests a device specific token, often called a device primary account number, from the card scheme. That token is stored in the secure element of the phone, a dedicated hardware chip isolated from the rest of the device, or in a secure cloud environment for wallets that use host card emulation. Each payment from the wallet uses this token, so the merchant never receives the real card number at all. Step one is enrolment, and the issuer must approve it. The customer adds the card in the wallet app, and the wallet sends a token request to the scheme with the card details. The scheme checks with the issuer, and the issuer verifies the cardholder, often by a one time passcode, a banking app approval, or a call to the bank. If verification passes, the scheme issues the device token and returns it to the wallet, where it is stored in the secure element. This enrolment step is what makes a wallet payment trustworthy later, because the issuer has already confirmed the cardholder. Step two is the payment, and it is authenticated on the device. At a shop terminal the customer holds the phone near the terminal, and at an online checkout the customer chooses the wallet button. The customer authenticates with a biometric, a fingerprint or face scan, or with the device passcode. This is known as consumer device cardholder verification, and it replaces the PIN or the signature. The wallet then builds the payment data: the device token, the amount, the merchant details, and a one time cryptogram generated for that specific transaction. Even if the payment data is intercepted, it cannot be reused, because the cryptogram is valid for one transaction only. Step three is the authorisation request, and it looks different from a standard card payment in two ways. The request carries the device token instead of the real card number, and it carries the cryptogram and the verification result instead of a PIN. The acquirer forwards the request to the scheme, the scheme detokenizes the token to the real number, validates the cryptogram, and routes the request to the issuer. The issuer checks the cryptogram, checks the funds and the fraud signals, and returns an approval or a decline with an approval code, exactly as for a normal card payment. Step four is what happens after the payment, and wallets must work like cards for the rest of the lifecycle. A refund is processed against the device token, and the scheme maps it back to the original card so the money returns to the right account. A chargeback follows the same dispute process as a card transaction, with the token recorded in the dispute evidence. Reconciliation must treat wallet transactions as card transactions with a token identifier, not as a separate payment type, or reporting will understate card volume and break the merchant settlement reconciliation. The analyst should confirm that refunds, chargebacks and reporting all carry the token through, end to end. Exceptions in wallets are specific and visible to the customer. If the device is lost, the customer or the issuer can suspend the device token remotely, and payments from that device stop immediately, even though the physical card still works. If the biometric fails repeatedly, the wallet falls back to the device passcode, and if that fails the payment is declined. If the cryptogram cannot be validated, the issuer declines with a fraud related response code. A token that is suspended or deleted, for example after a phone reset, must be re-enrolled before the wallet can pay again. Each of these needs a clear customer message, because the customer sees a wallet failure, not a card failure. For the analyst, wallet integration is a mapping exercise with real design decisions. Map the enrolment flow, the authentication methods, the token and cryptogram fields in the authorisation request, and the refund and chargeback flows. Confirm which wallets are supported at each merchant and channel, because Apple Pay, Google Pay and Samsung Pay differ in enrolment and in the data they return. Confirm how the merchant receipt shows a wallet payment, since it shows a token reference rather than the last four digits of the real card.