The following guides provide information on CardSecure, tokens, and the various tokenization methods available to fit your business needs.


CardSecure® is CardConnect's P2PE-validated encryption and tokenization solution, and is at the center of all integrated payment solutions. Whether you use Bolt P2PE to securely accept card-present transactions with your integrated point-of-sale solution, or the Hosted iFrame Tokenizer to extend secure eCommerce payments to online customers, CardSecure allows you to accept sensitive payment data securely, with reduced PCI scope.

Understanding CardConnect Tokens

CardConnect's patented CardSecure P2PE-validated tokenization solution offers numerous secure and convenient methods for tokenizing sensitive data. A token is a hashed alphanumeric representation of sensitive data such as a credit card account number. These tokens can only be used with the CardPointe Gateway API for transaction processing.

When you submit a tokenization request, CardSecure encrypts and stores the sensitive data in a secure vault, and generates a unique token that corresponds to and represents the stored data. For example, if you capture and tokenize payment card data, the payment card number and associated track and EMV data (for card-present transactions) is stored in the database. You then use the token to represent this payment card in a transaction.

CardSecure stores and purges sensitive data in accordance with Payment Card Industry (PCI) compliance standards. However, even after a token's sensitive data has been purged, CardSecure retains a hash of the clear card number, allowing the same token to be generated any time a given card is tokenized.

Consider the following information when handling tokens:

  • Tokens never expire. In the event that a card is re-swiped or manually keyed on a terminal a device, the same token is generated for that card.
  • Tokens can be alpha-numeric. The format of the token is driven by the specific key format used.
  • Credit card tokens are typically 16-digit numeric tokens, where: 
    • The 1st digit is always 9.
    • The 2nd and 3rd digits represent the first and second digits of the card number. You can use these to determine the card type, as follows:
      • 3X= Amex
      • 4X= Visa
      • 5X= Mastercard
      • 6X= Discover
    • The last 4 digits of the token represent the last 4 digits of the card.

Tokenizing Using CardSecure Mobile SDKs

The CardSecure Mobile SDKs seamlessly connect your iOS and Android applications to CardSecure for tokenization of customer card data. Tokens and other associated payment details are then retrieved by your server and securely transmitted to the CardPointe Gateway for authorization, using a server-side REST client.

Integrating the the mobile SDKs can help reduce your PCI scope. The SDKs provide direct tokenization methods that pass your customers' sensitive card data to CardConnect without ever sending the clear or unencrypted card data to your server.

The token returned from this process is not considered card data; therefore, as the token moves between your client application and your application server, the token does not bring any of those systems or data paths into scope for PCI security controls.

The following topics provide a general overview of the mobile SDKs. See the following guides for more detailed information, including integration details:

A complete mobile payment solution consists of two components:

  • Tokenization is handled by the SDK integrated with your mobile application.
  • Authorization is handled by host scripts integrated with your server application.

Tokenization (Client-side)

The SDK installs alongside your mobile application, and uses CardSecure to tokenize and encrypt payment card data. Card data can be manually entered in the application or captured, using a supported mobile payment reader device. Payment card data is encrypted and tokenized while being kept separate from your software application or server.

Additionally, tokens can be stored in customer profiles for use in subsequent transactions. 

Authorization (Server-side)

The CardPointe Gateway REST clients install on your application server to integrate your solution to the CardPointe Gateway.

Using a REST client, your sever authenticates with the CardPointe Gateway, makes authorization requests using tokens retrieved from the mobile app, and handles responses from the Gateway.

See Toolkit Introduction for information on using the CardPointe Gateway REST clients.

See the CardPointe Gateway API documentation for more information on the features and capabilities of the CardPointe Gateway.

Tokenization and Payment Flow

The following diagram illustrates the tokenization and payment flow using the iOS SDK and server-side REST client.

  1. Your mobile app collects payment card data from a connected mobile payment reader or by manual entry in the app and sends the data to CardSecure via the iOS SDK.
  2. CardSecure returns a token to the mobile app.
  3. The mobile app sends the token to your server, which is running a CardPointe Gateway REST client.
  4. Your server application uses the token to make an authorization request to the CardPointe Gateway, via the REST client.
  5. The CardPointe Gateway returns the authorization response to your server.
  6. Your server passes the authorization response to the mobile app.

Tokenizing Closed Loop Gift Cards

CardConnect allows merchants the flexibility to accept their own proprietary, closed loop gift cards for customer purchases. If you want to include closed loop gift cards in your accepted payment methods, review the following information to get started.

Gift Card Requirements

Before you begin, check with your gift card printer to verify that your gift cards meet the following requirements:

  • Cards must include a magnetic-stripe to provide track 2 data.
  • The track data must include an expiration date.
  • Cards numbers must pass Luhn algorithm verification.
  • Card numbers must not start with 9.
  • Card numbers must not be greater than 19 digits.
  • You must provide CardConnect with a unique Bank Identification Number (BIN) range for your gift cards. This range must not overlap any other BIN ranges.

If you currently use gift cards that do not meet all of these requirements, or if they are in a different BIN range, you will not be able to accept those gift cards.

Establishing a BIN Range

Before you can begin to accept gift card payments, you must provide CardConnect with the BIN range used to identify your gift cards. CardConnect uses this information to whitelist the specific BIN range, allowing CardSecure to return unencrypted clear text data to your point-of-sale software.

Contact CardConnect Support to get started.

The BIN range that you provide must be unique, and must not overlap any other BIN range.

Loading a Gift Card

When a customer purchases a gift card, the merchant initiates an authorization request using the customer's payment card. The authorization response data can then be used to update the merchant's ledger to include the transaction amount, the total amount added to the gift card, the quantity of gift cards, issued gift card numbers, and any additional identifying information for the transaction.

Accepting a Payment

When a customer presents a gift card for payment, the payment request process is similar to accepting a credit or debit card payment. 

Depending on your business needs, you can use Bolt to accept card-present gift card payments in person, or you can integrate CardSecure to allow customers to use gift cards to make payments on your website or mobile application.

Using Bolt

If you are using Bolt to process payments, you can use a readCard or readManual request to initiate a gift card transaction. When the gift card is swiped or manually entered at a Bolt terminal, Bolt matches the BIN with the range of BINs for your gift cards and returns an unencrypted clear text card number, which your point-of-sale software uses to complete the transaction.

Using CardSecure

If your software directly integrates CardSecure, using the CardSecure API, Hosted iFrame Tokenizer, or Mobile SDKs, your software passes the gift card number to CardSecure, which matches the BIN with the whitelisted BIN range and returns the unencrypted card number, which your software uses to complete the transaction.


  • Unlike a credit or debit card transaction, CardSecure does not encrypt or tokenize the gift card account number.
  • In the event that the gift card balance is insufficient to cover the full amount of the transaction, your software will need to initiate a second request to complete the transaction using another payment method.

Managing Gift Card Transactions

Because these gift card transactions take place within a closed loop, no settlement or funding data is passed to an issuing bank. Instead, it is the merchant or partner's responsibility to manage gift card transaction and funding data. By integrating the CardPointe Gateway API and Bolt P2PE API, your software can retrieve the data necessary for you to manage your general ledger, and to ensure that funds are transferred from the gift card to the merchant.

Tokenizing Interactive Voice Response Input

This guide provides information for tokenizing data gathered using an interactive voice response (IVR) telephone system.


Interactive voice response (IVR) systems are used to capture payment and personal information from customers using a telephone keypad or voice recognition. If your business uses an IVR system to capture sensitive data, you can integrate the CardSecure API with your solution to securely encrypt and tokenize the data and the CardPointe Gateway API to use the token to process a payment.


To tokenize data captured from an IVR system, your integration must meet the following requirements:

  • You must obtain an RSA public key from CardConnect.

    CardConnect generates a unique RSA key pair, provides the public key (in X.509 format) to you and retains the private key. You use the public key to encrypt the IVR input data, and CardSecure uses the private key to decrypt the data prior to tokenization. For more information, see Encrypting and Tokenizing Payment Account Data.
  • Your authorization requests to the CardPointe Gateway must include the key value pair "ecomind" : "T" to specify that the payment source is "telephone."

How it Works

The following workflow describes a typical process for capturing cardholder data with an IVR system, tokenizing the data, and processing a payment:

  1. A customer calls in to your service to make a payment.
  2. When prompted, the customer enters a credit card number, CVV code, and zip code using either Touch-Tone or voice recognition input.
  3. Your IVR software captures the customer's input. 
  4. Your application uses an RSA encryption key (provided by CardConnect) to encrypt the data.
  5. Your application makes a tokenization request, using the CardSecure API.
  6. CardSecure generates a token that represents the customer's payment card data, and returns the encrypted token to your application.
  7. Your application makes an authorization request, using the CardPointe Gateway API and the token.
  8. The CardPointe Gateway authorizes the payment and returns the authorization response to your application.