{"id":5025,"date":"2024-03-05T06:04:40","date_gmt":"2024-03-05T06:04:40","guid":{"rendered":"https:\/\/zv3d.wpengine.com\/us\/?p=5025"},"modified":"2025-01-29T15:21:38","modified_gmt":"2025-01-29T09:51:38","slug":"demystifying-tokenized-card-payments","status":"publish","type":"post","link":"https:\/\/www.zeta.tech\/us\/resources\/blog\/demystifying-tokenized-card-payments\/","title":{"rendered":"Token Talk: Demystifying Tokenized Card Payments for Modern Issuers"},"content":{"rendered":"
\n
Contents<\/div>\n
    \n
  1. Tokenized card transactions<\/strong><\/a><\/li>\n
  2. Token provisioning and lifecycle management<\/strong><\/a><\/li>\n
  3. Benefits of tokenization<\/strong><\/a><\/li>\n
  4. Preparing for a tokenized future of payments<\/strong><\/a><\/li>\n<\/ol>\n<\/section>\n

    In our previous <\/span>blog<\/span><\/a>, we understood how critical the ISO 8583 message protocol is in standardizing information exchange between the multiple entities involved in a card payment: Merchants, Acquirers, Schemes, and Issuers. We also saw, using a raw ISO 8583 message, how exactly critical card and transaction data is transferred. For example, data field 2 contains PAN (the actual card number), data field 14 (Expiration Date) contains the card expiry, data field 44 (Additional Response Code) contains card CVV, etc.\u00a0<\/span><\/p>\n

    As you can imagine, the impact of this data falling into the wrong hands is severe. Data breach concerns have driven the growing adoption of tokenization in card payments, which is essentially a method of replacing cardholders\u2019 sensitive PAN information with a unique alternative value for in-store and online transactions. Today, tokenized payment transactions are becoming mainstream, with Juniper Research estimating that tokenized payments will exceed $1 trillion in value globally by 20261<\/sup><\/a>.<\/span>\u00a0<\/span><\/p>\n

    In this context, enabling tokenized card payments has become a critical requirement for issuers, offering a range of business benefits – but also posing some technological challenges. We present a simplified overview of tokenized transactions, and the implications for issuers.<\/span><\/p>\n

    Tokenized card transactions<\/h2>\n

    Fraudsters use multiple tricks to obtain access to card information. They install card skimmers at POS or ATM terminals and use phishing, vishing, and social engineering to trick customers. An interesting question to ask is: What would happen if the most valuable data (card number and card expiry) to the fraudster in the payment is completely removed and replaced with similar-looking information? In such a scenario, fraudsters will find very little value from the compromised information. That is exactly what tokenization of card payments does. Replace the PAN (primary account number) with a unique alternative value: a payment token.<\/span><\/p>\n

    The payment tokenization specification was first published by EMVCo in March 2014 [EMVCo is a global organization that was established by major payment card brands, including Europay, Mastercard, Visa, JCB, American Express, and UnionPay to manage and enhance specifications for payment systems worldwide]. It defined Payment Tokenization as, \u201cthe process of replacing a Primary Account Number (PAN) and PAN Expiry Date with unique alternative values that can be defined in where and how it is used\u201d. For example, it could be designed to be used only at a single specific merchant; only on\/with a unique consumer device; and\/or only with a specific transaction type. The specification can be accessed <\/span>here<\/span><\/a>.<\/span><\/p>\n

    Image 1 shows a typical information exchange during a card payment looks like without and with tokenization.<\/span><\/p>\n

    Image 1<\/p>\n

    \"Information<\/p>\n

    As you can see, the usage of card account number (and even the card expiry) is eliminated in a large part of the information exchange chain. A token service provider (TSP) is responsible for generating as well as storing these tokens. The network scheme (Visa, MasterCard, EuroPay, etc) converts the token back to the PAN using the TSP before letting the issuer conduct all checks to determine whether the payment should be authorized or not.<\/span><\/p>\n

    What this means, however, is that the merchant needs to have the token for the corresponding card being used by the cardholder. That brings us to a new role in the tokenization ecosystem: the token requestor (TR). A token requestor registers with token service providers in order to request payment tokens on behalf of the merchant. For every card that needs to be tokenized, TRs fetch the token for a given PAN once before initiating a tokenized payment (Image 2).<\/span><\/p>\n

    Image 2<\/p>\n

    \"role<\/p>\n

    Token provisioning and token lifecycle management by issuers<\/h2>\n

    In order to enable tokenized card payments, the EMVCo specifies the following entities for the payment information exchange:\u00a0<\/span><\/p>\n