What Is a Token Scheme?

When it comes to your data, your organization’s specific use case will determine the type of data privacy and security needed. If you have researched tokenization, there is a good chance that you have come across the term token scheme. Keep reading to discover what a token scheme is and the different token formats that are available. With this knowledge, your business can be better informed when deciding which token format to implement into your existing environment.

A token scheme encapsulates the validation of input data and the token format returned to a client. At IXOPAY, token schemes are designed to facilitate multi-data set acceptance without impeding critical business processes or existing applications. Other names for token schemes include token formats, which can be used interchangeably. Scheme tokens also refer to network tokens, which are used to process secure and more efficient card payments for merchants.

Token formats can either be single or multi-use. The type of token format will always depend on the organization’s use case. The token and input data have a 1:1 mapping with a multi-use token scheme. This means that when a business sends the same input data numerous times, it will always receive the same token value. On the other hand, a single-use token scheme means that a new token value will be received every time.

For example, a merchant that accepts card payments may need the bank identification number (BIN) from credit cards. In this use case, the client would benefit from a format-preserving token scheme, which can retain the first 6 digits from the input data. Indeed, this token format helps maintain existing business utility while also securing sensitive payment data within a tokenized environment and staying out of compliance scope.

Depending on which tokenization platform you partner with, there are typically different token formats offered to clients. IXOPAY is the only tokenization solution offering a diverse range of token schemes from PCI to ASCII. IXOPAY offers the following token formats for businesses to choose the best token formats for their use case. Indeed, we can tokenize any structured data type.

Description: This token returns an alphanumeric, length-preserving token that retains the last 4 digits from the input data (ideal for clients that process card payments).

• Input Validation: It accepts numeric values from 0 to 9.
• Input Length: 9-512
• Token Mapping: 1:1
• JSON value: 29

Description: This token format returns an alphanumeric, length-preserving token.

• Input Validation: It accepts numeric values from 0 to 9.
• Input Length: 5-512
• Token Mapping: 1:1
• JSON value: 30

Description: This token format returns an alphanumeric token but doubles the length of the input.

• Input Validation: It accepts any ASCII characters.
• Input Length: 5-128
• Token Mapping: 1:1
• JSON value: 27

Description: This token format returns an alphanumeric, length-preserving token. For input data greater than or equal to 15 digits, the token will retain the first 6 and last 4 digits. For input data less than 15 digits, the token will retain the first 4 and last 4 digits.

• Input Validation: It accepts Luhn-compliant numeric values (0-9).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 26

Description: This token format returns an alphanumeric, length-preserving token. For input data greater than or equal to 15 digits, the token will retain the first 6 and last 4 digits. For input data less than 15 digits, the token will retain the first 4 and last 4 digits.

• Input Validation: It accepts Luhn-compliant numeric values (0-9).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 26

Description: This token format returns an alphanumeric, upper case, length-preserving token retaining the original first 6 and last 4 digits of the input data.

• Input Validation: It accepts alphanumeric values (a-Z, 0-9).
• Input Length: 14-38
• Token Mapping: 1:1
• JSON value: 9

Description: This token format returns a Luhn-compliant token that retains the card number’s original first 6 and last 4 digits.

• Input Validation: It accepts numeric values from 0 to 9 (Luhn-compliant).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 1

Description: This token format returns a non-Luhn-compliant token that retains the card number’s original first 6 and last 4 digits.

• Input Validation: It accepts numeric values from 0 to 9 (Luhn-compliant).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 23

Description: This token format returns a numeric, length-preserving token that retains the input data’s original first 6 and last 4 digits.

• Input Validation: It accepts numeric values from 0 to 9.
• Input Length: 14-38
• Token Mapping: 1:1
• JSON value: 19

Description: This token format returns an ASCII, length-preserving token that retains the input data’s original first 6 and last 4 digits.

• Input Validation: It accepts any ASCII characters.
• Input Length: 14-38
• Token Mapping: 1:1
• JSON value: 16

Description: This token format returns an alphanumeric, length-preserving token that retains the original first 4 and last 4 digits of the input data.

• Input Validation: It accepts alphanumeric values (a-Z, 0-9).
• Input Length: 12-38
• Token Mapping: 1:1
• JSON value: 10

Description: This token format returns a Luhn-compliant token that retains the card number’s original first 4 and last 4 digits.

• Input Validation: It accepts numeric values from 0 to 9 (Luhn-compliant).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 2

Description: This token format returns a non-Luhn-compliant token that retains the card number’s original first 4 and last 4 digits.

• Input Validation: It accepts numeric values from 0 to 9 (Luhn-compliant).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 24

Description: This token format returns a numeric length-preserving token that retains the original first 4 and last 4 digits of the card number.

• Input Validation: It accepts numeric values from 0 to 9.
• Input Length: 12-38
• Token Mapping: 1:1
• JSON value: 20

Description: This token format returns an ASCII, length-preserving token that retains the original first 4 and last 4 digits of the input data.

• Input Validation: It accepts any ASCII characters.
• Input Length: 12-38
• Token Mapping: 1:1
• JSON value: 17

Description: This token format returns an alphanumeric, length-preserving token.

• Input Validation: It accepts alphanumeric values (a-Z, 0-9).
• Input Length: 4-38
• Token Mapping: 1:1
• JSON value: 12

Description: This token format returns an alphanumeric, length-preserving token that retains the original last 4 digits of the input data.

• Input Validation: It accepts alphanumeric values (a-Z, 0-9).
• Input Length: 8-38
• Token Mapping: 1:1
• JSON value: 11

Description: This token format automatically selects an ANTOKEN type token scheme to retain the maximum number of original characters.

• Input Validation: It accepts alphanumeric values (a-Z, 0-9).
• Input Length: 4-38
• Token Mapping: 1:1
• JSON value: 13

Description: This token format returns an ASCII, length-preserving token.

• Input Validation: It accepts any ASCII characters.
• Input Length: 4-38
• Token Mapping: 1:1
• JSON value: 15

Description: This token format returns an ASCII, length-preserving token that retains the original last 4 digits of the input data.

• Input Validation: It accepts any ASCII characters.
• Input Length: 8-38
• Token Mapping: 1:1
• JSON value: 14

Description: This token format automatically selects an ASCIITOKEN token scheme to retain the maximum number of original characters.

• Input Validation: It accepts any ASCII characters.
• Input Length: 4-38
• Token Mapping: 1:1
• JSON value: 18

Description: This token format requires no validation and will return a GUID as the token.

• Input Validation: None
• Input Length: 1-1000
• Token Mapping: 1:Many
• JSON value: 4

Description: This token format is used to tokenize any number combination.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 1-1000
• Token Mapping: 1:1
• JSON value: 6

Description: This token format returns a numeric, length-preserving token.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 4-38
• Token Mapping: 1:Many
• JSON value: 8

Description: This token format returns a numeric token while retaining the length and last 4 digits of the input data.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 8-38
• Token Mapping: 1:Many
• JSON value: 7

Description: This token format returns a numeric token while retaining the length and last 4 digits of the input data.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 8-38
• Token Mapping: 1:1
• JSON value: 28

Description: This token format automatically selects the NTOKEN token scheme to retain the maximum number of original characters.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 8-38
• Token Mapping: 1:1
• JSON value: 21

Description: This token format is used to tokenize a Social Security number.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 9
• Token Mapping: 1:1
• JSON value: 5

Description: This token format requires no validation and will return a random 38-character alphanumeric token.

• Input Validation: None.
• Input Length: 4-1000
• Token Mapping: 1:1
• JSON value: 22

Description: This token format will return a Luhn-compliant token retaining the original last 4 digits of the card number.

• Input Validation: It accepts numeric values from 0-9 (Luhn-compliant).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 3

Description: This token format will return a non-Luhn-compliant token that retains the original last 4 digits of the card number.

• Input Validation: It accepts numeric values from 0-9 (Luhn-compliant).
• Input Length: 13-19
• Token Mapping: 1:1
• JSON value: 25

Description: This token format will return a 9-digit numeric token retaining the last 4 digits of the input value.

• Input Validation: It accepts numeric values (0-9).
• Input Length: 9
• Token Mapping: 1:1
• JSON value: 32

Since token schemes can be used for any data type, this provides the flexibility to create a customized solution for businesses. Indeed, IXOPAY can secure and desensitize all types of data, thus allowing clients to use custom tokens that are alphanumeric, Luhn-compliant, length- and format-preserving, and fully functional with their existing business systems. For example, one of our clients, MRC Global, needed a vendor that could tokenize three different types of data – payment card data, personally identifiable information (PII), and unstructured data. This client discovered the IXOPAY Data Protection platform, which allowed them to create a customized token scheme solution that other tokenization providers failed to offer.

Furthermore, a client’s use case may require a unique token scheme that provides 1:1 or 1:Many mapping. For example, a merchant may need a 1:1 token regarding primary account numbers (PANs) from customers’ credit and debit cards stored on their ecommerce website. With a 1:1 token, the PAN will retain the same token value, which is necessary for merchants that offer recurring billing services. However, a different business may need a 1:Many token to repeat a single data point multiple times. For instance, a company could use a 1:Many token scheme to ensure that the output token will be different when the same customer’s date or name is sent. Indeed, this token will protect the client from data breaches and prevent cyber criminals from deciphering the input data.

In addition to flexible, customizable token schemes, IXOPAY also offers data protection and security through our cloud tokenization platform. As a leading global tokenization provider, we are dedicated to protecting the world’s most sensitive data, helping businesses maintain critical business utility, and ensuring they comply with regulatory standards. If you are interested in learning more about token schemes, data tokenization, or other services, contact us today. Our expert team would love to meet you and learn how we may be a good fit for your organization.