Tokens and stored credentials.

The quick reference

DPAN or FPAN: which number travels when

This is the question that trips up most teams. The answer depends on two things: how the customer pays (physical card, phone wallet, typed card, saved card) and which hop of the journey you are looking at. A single payment can start as a DPAN and arrive at the issuer as an FPAN.

Pick a scenario. The strip shows which number is on each hop, and where the swap happens.

The rules of thumb

The issuer ends up with the FPAN. Whatever token the customer presents, it is swapped back before the issuer decides. The issuer also receives token details, so it knows the payment came from a wallet or a merchant token.

The swap usually happens at the card network, in its token service. Some issuers run their own token service and do the swap themselves. Merchants, gateways, and acquirers pass the token through untouched.

A DPAN means “this device, right now.” Use it for the purchase in front of you. Do not rely on it for charges months later, because a new phone means a new DPAN.

For future charges, store something that outlives the device: an MPAN for Apple Pay subscriptions (Google Pay offers a similar merchant token when you request it for merchant-initiated use), a merchant network token for typed cards, or an FPAN in your provider's vault with an account updater service as the fallback.

Google Pay comes in two forms. A card tokenized on an Android phone arrives as a DPAN with a cryptogram (Google calls this CRYPTOGRAM_3DS). A card simply saved to the shopper's Google account, common on desktop browsers and iPhones, arrives as the card number itself with no cryptogram (PAN_ONLY). Treat the second like a typed card: run 3-D Secure if you want fraud liability protection.

Who sees which number

What happens when life changes

This table is why the choice matters. It shows what happens to a credential you stored when the customer's card or phone changes.

Two operational traps. First, wallet payments made with a device token print the device number's last four digits on the receipt, not the card's. A cashier who checks the last four against the customer's physical card will see a mismatch on a legitimate return. Train staff to have the customer tap the same device, or look the order up by receipt. Second, fraud rules and “have we seen this card before” logic keyed on last four or on a token break across wallets. Where PAR is available, key on it: it links a card and its tokens, though not every issuer or processor returns it.

How a wallet payment gets back to the real card

When a shopper pays with a phone wallet, the merchant never sees the card number. The device sends a DPAN and a one-time cryptogram. The card network checks the cryptogram, swaps the token for the FPAN, and sends both to the issuer. Step through it.

Stored credentials and standing instructions

Saving a card so you can charge it later is called a stored credential, or card on file. The card networks have rules for it, often called the stored credential framework. The rules exist so the issuer knows whether the customer is present, and can approve a charge they would otherwise treat as suspicious.

Every stored credential starts with a customer-initiated transaction (CIT): the customer is present, agrees to the terms, and you tell the issuer you are storing the card. The authorization response includes a network transaction ID, assigned by the card network. Later, when you charge without the customer present, that is a merchant-initiated transaction (MIT), and you send that original ID so the issuer can link the charge back to the customer's consent.

MITs come in two families. Knowing the family tells you which indicator to send.

Why this matters for checkout. The “Save this card” checkbox is not a UI nicety. It is the consent record for every future MIT. Store the agreement terms, the token, and the original network transaction ID together on the customer's wallet record. If a dispute arrives months later, that record is your evidence.

Field names differ by provider (for example “stored credential indicator,” “initiator,” or “subsequent auth”). Card brands also have their own variants, such as Mastercard's standing order and subscription categories. Check your gateway's documentation for exact values.