Payeezy Gateway users have access to First Data’s TransArmor® product which uses tokenization technology to remove the need for merchants to store card data by replacing it with a randomly assigned number, called a 'token', after authorization. In doing so, TransArmor minimizes risk by reducing the scope of PCI compliance, shifts the burden of protecting cardholder data from you to First Data, and allows the 'token' to be used for other business and sales functions such as returns, sales reports, analysis, etc.
Reduce your PCI Scope and resources needed to meet PCI requirements
The TransArmor product meets the PCI Security Standards Council guidelines for tokenization. Removing payment card data from your systems may also reduce your overall PCI scope. Additionally, the time and resources needed to meet PCI requirements may be reduced.
- Card-based, random-number tokenization—completely removes sensitive cardholder information from the merchant by replacing the Personal Account Number (PAN) with a random token value
- The format-preserving token value can be used in place of the PAN to continue to support business analytics and reports, anti-fraud activities, etc.
How the TransArmor Solution Works within Payeezy Gateway
- Payment card information is keyed into merchant’s payment page (Hosted Checkout or Web Service API)
- Personal Account Number (PAN) and expiration date are sent to the Payeezy Gateway.
- Payeezy Gateway builds a message to the switch that includes the data elements captured by the merchant.
- Card number is passed to bank for authorization using SSL encryption and also to First Data for tokenization
- Authorization and token number are returned to the merchant
- Token number replaces card number in all subsequent instances and activities such as analytics, marketing, etc.
- Settlement, adjustments, refunds, chargebacks and other activities are performed using the token number in place of the card number
Using TransArmor Tokens with a Test Account
In the test account environment the TransArmor token is returned as random letters and numbers with the last 4 digits the same as the card number. In the production environment the token is returned as only random numbers with the last 4 digits the same as the card number.
The original concept of the token meant that the merchant could not use this random number to perform a subsequent financial transaction, because it is not a valid PAN. However, a multi-pay token adds the ability to perform an authorized financial transaction under strict control measures within the merchant environment. The merchant submits a token that it already has on file for a specific consumer/card to First Data who accesses the vault to retrieve the PAN and complete the transaction. By using this type of token in the payment authorization process, the merchant reduces the risk of having the real PAN stolen as it is being collected from the consumer or stored by the merchant.
Multi-pay tokens are especially valuable in eCommerce and other CNP environments that tend to store payment card information in a virtual wallet or on their website for repeat customers. The multi-pay token allows a merchant to tokenize the payment card information, associate that token with the consumer profile stored on the merchant side, and then use the token with the processor gateway that holds the token vault in order to run subsequent transactions. This is done without the need to prompt the customer for his card account number again, and without having to store the actual card number.
For more information on the benefits of multi-pay tokens, please read our white paper:
How Multi-Pay Tokens Can Reduce Security Risks and the PCI Compliance Burden for eCommerce Merchants