Skip to content →

Token Requestors

Token requestors are entities that provide a service directly or indirectly to cardholders that requires the collection and storage of cardholder PANs. There are 2 types of tokens: Mobile Device-Bound and Non-Device-Bound; these are explained below.

Mobile Device-Bound Tokens

Mobile Device-bound tokens are those that are provisioned to a mobile device for use in contactless payments or mobile application-based payments.

  • Third-Party Wallets such as Android Pay and Samsung Pay already tokenize card payments for in-app purchases made through their merchants’ mobile applications.
  • HCE Service tokens issued in the device-bound case are kept separate for NFC and In-App device-bound tokens. NFC tokens are requested by and kept in the Visa/MC/RuPay Ready SDKs, the In-App tokens are kept in the HCEWALLET SDK and E-commerce shared tokens are kept in the host HCE SWIM MAP platform. HCE Service client issuer/wallet-provider/direct-merchant token requestor must be duly on-boarded in VTS, RuPay and MDES in order to receive these tokens for in-app transactions.

Non-Device-Bound Tokens

Non-device-bound tokens are not bound to a specific device and are used for online e-commerce transactions without use of mobile devices. Following are supported non-device-bound token requestors that can request non-device-bound tokens from card schemes token services:

  • E-Commerce Enablers receive a shared token for the same PAN and must request a cryptogram for the token from VTS before placing an authorisation. HCE Service HCEWALLET service is effectively an e-commerce enabler (similar to Visa Checkout). E-commerce enablers may have merchants integrated to them, and these merchants in turn receive token information from the e-commerce enabler (therefore, these merchants are not token requestors themselves). Merchants that receive token information from e-commerce enablers are referred to as “indirect merchants”.
  • Direct Merchants (Merchants as Token Requestors with Cards on File): Direct merchants are card-on-file (COF) merchants that integrate directly with token services as token requestors. Direct merchants receive unique tokens for PANs from card scheme token services (such as VTS, MDES, RuPay) and use these tokens on file to conduct transactions similar to card-on-file transactions. Direct merchants must take appropriate steps to support the appropriate token fields (e.g., cryptogram, token, electronic commerce indicator (ECI), etc.).

HCEWALLET App TR

HCE Service aims to request Visa/MC/RuPay representatives to register HCEWALLET as a token requestor (TR) to enable indirect merchants to use tokenisation. Card Schemes need to perform TR account registration (on-boarding) process and assign a provider ID to HCEWALLET and other client (e.g. payment aggregators and direct merchants) token requestors of HCE Service. Account registration involves collecting information about the organisation and compliance verification.

Indirect Merchants (Integrated with HCEWALLET App TR)

Token Processing Indirect merchants must request token credentials (token and cryptogram) for every new authorisation.

  • Token details must be populated in the transaction authorisation message.
  • Indirect merchants must validate that the cryptogram is used within the expiration window.
  • A new cryptogram is required for all new original transaction authorisations.
  • Indirect merchants must use the token range (i.e., first nine digits) for BIN lookup.
  • Token requestor should use only active tokens in authorisations. Deleted or suspended tokens result in authorisation failures.
  • Card schemes recommends that merchants include appropriate messaging to educate cardholders on tokenisation.
  • Indirect merchants must use the term “digital account number” for cardholder display purposes.
  • For consumer-receipt purposes, where the card expiration date is used today, the last four digits of the PAN without the expiration date must be used for display purposes.

E-Commerce Enablers and Third-Party Wallets TR

Token processing Token Requestor must provide the ability for its payment acceptors (i.e., merchants, gateways, acquirers, etc.) to request cryptograms for provisioned tokens when they want to run authorisations. ECI token details, including ECI indicator and cryptogram, must be forwarded to the underlying payment acceptor for transaction processing. Full card account number is not shared with the merchant when providing token details.

  • Token requestor must use the token range (i.e., first nine digits) for BIN lookup.
  • Token requestor should use only active tokens in authorisations. Deleted or suspended tokens result in authorisation failures.
  • After the card number is tokenised, card schemes recommends that token requestors not store the card number for that token.
  • Lifecycle Management Implement Delete token. Receive token notification.
  • Implement Suspend and Resume token.
  • Token requestors may include appropriate messaging to educate cardholders on tokenisation.
  • Tokens cannot be auto-filled/key-entered in the browser.
  • Token requestors must use the term “digital account number” instead of the term “token” in all their communications with the cardholder.

For consumer-receipt purposes, where the card expiration date is used today, the last four digits of the PAN without the expiration date must be used for display purposes.

Direct Merchants (Merchants with Cards on File)

Token Provisioning Direct merchants must present their Visa tokenisation content in the service terms and privacy policies to the cardholder prior to provisioning a token.

  • Direct merchants should provide the relationship type they have with the cardholder (e.g., one-time guest transaction or performed by a cardholder).
  • Token Processing Direct merchants must have or provide the ability for their payment acceptors (self or gateways, acquirers, etc.) to request cryptograms for provisioned tokens when they want to run authorisations.
  • ECI token details including ECI indicator and cryptogram must be forwarded to the underlying payment acceptor for transaction processing.
  • When a direct merchant’s attempt to tokenize a card fails, the direct merchant should follow business as usual practices.
  • Direct merchants must use the token range (i.e., first nine digits) for BIN lookup.
  • Token requestors should use only active tokens in authorisations. Deleted or suspended tokens result in authorization failures.
  • After the card number is tokenized, Visa and MC recommend that token requestors not store the card number for that token.
  • Lifecycle Management Implement Delete token. Receive token notification.
  • Implement Suspend and Resume token.
  • Direct merchants may include appropriate messaging to educate cardholders on tokenization.
  • Tokens cannot be auto-filled/key-entered in the browser.
  • Direct merchants must use the term “digital account number” instead of the term “token” in all their communication with the cardholder.
  • For consumer-receipt purposes, where the card expiration date is used today, the last four digits of the PAN without the expiration date must be used for display purposes.

TR Use Cases

This section describes the branding and user experience use cases and requirements for integrating with Token Services.

  • When a cardholder adds a card to his or her account, the token requestor should be able to tokenise the card.
  • The merchant must be able to verify the token details provided by the token requestor on behalf of cardholder. Account verification is not available using token and cryptogram.
  • When online shopping at a merchant website, the cardholder wants to be able to check out using an e-commerce enabler account by first adding a new card, then immediately using it to complete an online purchase. This use case combines two of the use cases above, where an e-commerce enabler tokenises a card when the cardholder adds it and immediately obtains cryptogram for the token in order to complete the purchase.
  • The cardholder wants to be able to check out via the e-commerce enabler as a guest user by adding a card and using it for completing the online purchase, without requiring creation of an e-commerce enabler account. This use case arises when e-commerce enablers allow their cardholders to complete purchases at a merchant without requiring them to create accounts. In this process the cardholder selects the option to check out as a guest, provides card information, and uses it to complete the purchase. Note that the cardholder may have previously registered an account with the e-commerce enabler, and yet may have chosen to complete the transaction as a guest; and the card used by the e-commerce enabler may have been tokenised earlier in an earlier transaction as the cardholder could have added the same card details to his or her account.
  • The token requestor wants to provide merchants the ability to bill their customers on a regular basis for recurring services such as bill payments, membership fees, insurance premiums, and subscriptions.
  • When a cardholder orders multiple items at a merchant’s website, and not all of the items are available for immediate shipment (which results in multiple shipments at different times), the merchant wants to be able to handle the situation depending on the knowledge of the product availability, and be able to process transactions and handle split payments for token transactions. For example, the consumer places a $100 order containing four $25 items at a merchant. When it is time to fulfil the order only one $25 item is ready to ship; the remaining three items are placed on back-order and will ship later. The merchant’s handling of this situation depends upon the knowledge of the product shipment availability at the time of order. An example of a recurring transaction is as follows:
  • The four items the cardholder ordered are available to ship on day 1, 2, 3, and 4, respectively.
  • The merchant authorises and settles $25 on day 1 for the first item’s shipment.
  • The merchant repeats the authorisation and settlement for the remaining items on days 2, 3, and 4, respectively
  • The cardholder wants to be able to pre-order items from merchants that offer them ahead of the availability date.
  • This use case depicts an end-to-end flow from a merchant who submits an authorisation request after a cardholder completes a payment online and receives a response from its acquiring entity.
  • The merchant wants to understand token requirements for transactions, including captures, reversals, and refunds that are performed as part of the lifecycle of a transaction beyond the original purchase. It is important to note that:
    • Cryptograms are required ONLY for original purchases.
    • Cryptograms are not required for subsequent processing, such as captures, reversals, or refunds.
  • Note: Refunds on tokens can be handled by performing a follow-on refund linked to the original purchase, thereby essentially reversing it.