Underlying account number
The primary account number identifies the card account within the conventional card-payment system. A payment-token flow is designed so the token can stand in for that number within its permitted use.
Digital wallet payment fundamentals
A digital wallet token is a substitute payment value associated with an underlying payment credential for use within a defined tokenized payment flow. Instead of presenting the card's primary account number throughout that flow, a participating wallet can present a payment token and related transaction data.
The word token is used for several different payment technologies, so merchants should identify which token is being discussed. An EMV payment token connected with a digital wallet is not automatically the same as a gateway's saved-payment-method identifier, an internal customer reference, or the transaction-specific cryptogram that can accompany a tokenized payment.
In EMVCo's online-wallet example, a cardholder adds a payment credential to a wallet. The wallet provider acting as a token requestor sends a token request through the token service process, and a payment token plus related data is provisioned to a designated token location after the applicable checks and issuer involvement. The consumer can later select that credential during checkout.
For a tokenized transaction, the wallet presents the payment token and related data, and the merchant's payment environment submits the token payment request through the existing payment ecosystem. The precise parties, data fields, security values, and processing path vary by wallet, payment network, acceptance channel, gateway, acquirer, and implementation. This general sequence should therefore be used as a map for asking questions, not as a configuration guide for a specific product.
The primary account number identifies the card account within the conventional card-payment system. A payment-token flow is designed so the token can stand in for that number within its permitted use.
The payment token is the substitute value used for token processing. Its use may be constrained by controls such as the requesting party, merchant, device, or presentation mode, depending on the token program and use case.
A token cryptogram or another transaction security value may accompany a wallet transaction. It supports transaction-specific processing and should not be described as though it were the reusable payment token itself.
A provider may return a customer ID, vaulted-payment reference, or gateway token for later merchant use. Its scope and portability are provider-specific and cannot be inferred merely because the interface calls it a token.
A merchant may see a wallet name, a payment-method label, limited card details, a token-related account reference, or normal authorization and settlement records. Those displays do not necessarily reveal every value passed among the wallet, gateway, acquirer, network, and issuer. For example, Google's current device-tokenization documentation describes a device payment flow that sends a device PAN rather than the funding PAN, while Apple's security documentation describes using a Device Account Number and a unique security code after user authentication.
Those are provider examples, not universal labels. A receipt's last four digits may differ from the physical card, and a report may identify the wallet or tokenized credential in a provider-specific field. Staff should use the processor or gateway's documented search fields when locating a transaction instead of assuming that the digits printed on the card will always match the payment record.
Tokenization can reduce how often the underlying account number is presented in a wallet transaction and can place controls around where a payment token is used. It does not make a transaction automatically legitimate, eliminate every data-security responsibility, guarantee authorization, prevent disputes, or establish that a merchant's current equipment and provider support a particular wallet.
A wallet token also does not replace customer authentication. Device unlock, wallet verification, payment-token issuance, transaction security data, merchant fraud controls, and issuer authorization are distinct parts of the broader flow. Their exact roles vary. Merchants should avoid marketing statements that compress all of them into a claim that a wallet payment is universally safer or cannot be misused.
Identify whether the intended use is contactless checkout, an app, a browser checkout, an invoice, or another channel. Token behavior and the merchant's integration tasks can differ by channel.
Ask the current processor, gateway, POS provider, or ecommerce provider which wallet methods are supported in the specific merchant configuration. Request current documentation rather than relying on a device logo or a generic feature list.
Learn how wallet payments appear in authorization responses, receipts, settlement reports, refunds, and customer-service searches. Document the supported way to find a transaction when displayed digits differ.
Use the provider's approved test method to check payment, receipt, reporting, refund, and staff-support steps before broad release. Do not enter real card data into an unapproved test form or support message.
The useful next step is to document the desired wallet and acceptance channel, then ask the responsible payment providers how tokenized transactions are enabled, identified, reported, refunded, and supported for the merchant's exact setup. Payments Max can help organize those evaluation questions without claiming universal support or compatibility.
Do not submit cardholder data, complete account numbers, wallet credentials, device passcodes, bank credentials, payment tokens, cryptograms, or API keys through a general inquiry form.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US