# Understanding Card Tokens Current card association regulations specify that a merchant must encrypt all stored payment card numbers. Furthermore, these regulations do not allow the storing of card track information or card security codes (CSCs). Using Shift4’ tokenization eliminates the need for both encryption key management and encryption algorithm maintenance in your interface. Tokenization is not encryption, but works together with our True P2PE® solution to relieve the merchant and the interface from the burden of storing, processing, and transmitting sensitive cardholder data (CHD), greatly reducing the scope of PCI DSS assessments and nearly eliminating the risk of a data breach. A card token is a unique, 16-character value created by Shift4's Gateway to reference CHD. In and of itself, a card token has no meaning and no decipherable relationship to CHD. The token is format-preserving and repeatable. ## Repeatable Repeatable tokens create a 1:1 relationship between the token and the PAN. Repeatable tokens will be reissued indefinitely within and among a predefined specific merchant environment. Because the same token is returned for a given PAN within a merchant’s environment, the token can be used for services such as e-folio, analytics, folio consolidation, loyalty promotions, fraud detection tools, back-office processes, and any system where the PAN is needed to identify a customer. ## Format-Preserving Global Token Vault (GTV) tokens are card-based (repeatable), format-preserving tokens. This means that they preserve many of the elements of an actual credit card. The following is a brief summary of the details of the token: - 16 numeric digits long, regardless of the length of the credit card length or card prefix (BIN) - Tokens do not contain any alpha or special characters - The first digit of the token is always an “8” - The second and third digits generally identify the card brand. The default mappings are below but these can be customized for a merchant if needed. - 00 = Unknown - 03 = American Express - 04 = Visa - 05 = MasterCard - 06 = Discover - 35 = JCB - 36 = Diners - 61 = PayPal - 62 = China Union Pay (CUP) - 90 = Gift Card - The last 4 digits of the token are the last four digits of the actual card number GTV Format - All tokens from the default vault pass a Luhn Mod 10 test - Custom tokens that do not pass Luhn Mod 10 test can also be created - Tokens are not tied to expiration dates, so they do not expire - Tokens are assigned when created - not derived from an algorithm so no reverse engineering Whenever the payment card number is used in a request, a card token will be returned in the corresponding response in the `card.token.value` field. Your interface should be designed to store this card token for future use. **WARNING! Sending both the payment card number and a card token in a request will result in an error.** ## Card Token Expiration Tokens never expire even if the card does. In the case the card has expired you can send the same card and new expiration date for a sale or in a tokenization request to update the expiration date Shift4 has saved with that token. ## Vaults and Token Sharing Global Token Vault creates unique “vaults” for each GTV ID. GTV IDs can be created per merchant or can be shared across a number of affiliated (branded or chain) merchants. Any merchants sharing a vault are able to securely share tokens within their vault. The same token will be returned for a credit card number within a merchant’s Global Token Vault. When merchants share tokens, it: - Enables analytics across their vault network - Eases accounting and reconciliation activities - Creates a 1:1 relationship between a token and the customer A merchant environment can be defined by: - **Outlet or terminal**: A single standalone outlet or terminal ID - **Property**: A location with multiple outlets or terminals - **Chain**: A local or regional restaurant with multiple locations or a group of affiliated hotels using common technology (e.g., reservation system) - **Brand**: A regional or national company consisting of many properties or multiple chains and potentially owned-and-managed or corporate-owned locations - **Corporation**: A national or international company with many properties, chains, or brands ## TokenStore Functions Shift4 has the TokenStore function to allow you to tokenize CHD. ### TokenStore Add [TokenStore Add](/apis/payments-platform-rest/openapi/tokens/tokensadd) is used to add CHD to the merchants’s Global Token Vault and receive a card token. Common uses of TokenStore Add are card-on-file processing or collecting CHD when an order or reservation is placed but not billed right away. TokenStore Add is sent when a purchase is not immediately processed and CHD needs to be tokenized for later use ### Use Case: TokenStore Add #### Actors: Interface, Shift4 #### Preconditions: CHD has been captured by a merchant and is ready for the interface to send. #### Main Flow: This flow illustrates receiving a card token for a card. 1. The interface sends the [TokenStore Add](/apis/payments-platform-rest/openapi/tokens/tokensadd) request using the merchant’s Global Token Vault. 2. Shift4 returns a response with a card token in the `card.token.value` field. 3. The interface vendor stores the card token instead of CHD in its database for use in subsequent transactions. #### Optional Flow: This flow illustrates validating a card before storing a card token. 1. A [Verify Card](/apis/payments-platform-rest/openapi/cards/cardsverify) request is sent using the resultant card token. 2. Include `customer` and `card.securityCode` fields in the verify request if you want cvv and avs to also be validated with the card number. 3. A response with no errors is received. 4. The interface interrogates the `transaction.responseCode`, `transaction.avs.valid`, and `card.securityCode.valid` fields (where applicable), and stores the card token if valid. #### Post Conditions: The token returned remains the same for the card in question and the token can be shared with any vendor that has the same GTVID setup on their account.