Tokenization

Overview

The process of providing a merchant with a unique identifier or “token” that can be used in place of card holder data (CHD) or checking account data is now commonly referred to as “tokenization”. Different payment processors may use different systems to accomplish this goal, but the end result is the same. The token, provided to the merchant by the payment gateway, can be used to perform secondary actions on existing transactions; and with most payment processors, the token can be used to create new payment transactions without the need to store the customer’s CHD in the merchant’s business application software. The token is unique to the payment processor and merchant and has a limited lifespan, as determined by the payment processor.

How does it work?

1. The Customer goes to the Merchant’s brick and mortar store, web site, or calls the Merchant to place an order.
2. The Customer provides the Merchant with their credit card or check data to pay for the order.
3. The initial transaction, an Authorization or Sale, is run using the Customer’s credit card or check data, which is given to the Payment Processor.
4. The Payment Processor stores the customer’s credit card or check data within their system and then returns a “token” to the Merchant.
5. The Merchant discards the credit card or check data in favor of the token, which can be stored safely by the Merchant.
6. The Merchant can then use the token for secondary actions, such as capturing the payment, issuing a credit against the transaction or voiding a transaction.
7. The Merchant may also be able to use the token to initiate new payment transactions against the credit card or check data that is associated with the token, depending on the payment processor. Every payment processor does not allow that, check with your provider.

How do Payment Processors Implement “Tokenization”?

There are several different methods by which Payment Gateways have instituted this concept. They are:

1. The Payment Processor may allow the use of a “Transaction ID” for secondary actions and new payment actions – in this scenario, the “Transaction ID” is the “token”.
2. The Payment Processor may have a separate “customer management system” that allows one or more payment methods to be recorded per “customer”. A token is generated to identify the customer/payment combination to use for new transactions. Secondary actions on a payment are then processed using the Transaction ID (not token) from the original authorization/sale while all new payments are initiated using the token.
3. The Payment Processor may provide both a Token AND Transaction ID in response to a new payment request. Token and Transaction ID are required for secondary actions on that payment and Token can be used for new payments (similar to bullet #2) which will apply the payment information recorded with the original transaction that spawned the token.