Ecommerce Tokenization: Understanding Methods that Keep Card Data Safe
Credit cards add a lot of flexibility to the way customers pay for goods and services. This convenience, however, comes at the cost of an increased risk of theft, especially through the internet. To help minimize this risk, the Payment Card Industry (PCI) provides comprehensive standards and resources to help organizations ensure the security of cardholder information at all times.
PCI compliance can be complex and expensive for small merchants. Clover Ecommerce developer APIs are designed to reduce your PCI compliance burden as well as that of your merchants.
PCI DSS compliance made easy with tokenization
One of the key methods for complying with PCI DSS is tokenization. Tokenization is the process of substituting sensitive data, such as credit card numbers, with a non-sensitive equivalent value called a token. A token cannot be reverse-engineered by a third party to get the original sensitive data. By using a token in place of raw credit card data, we can minimize the risk of handling sensitive data in transit and at rest. Clover tokens are used to securely gather sensitive data from customers for additional processing. Currently tokens are used for both credit and debit cards.
Detokenization in the Clover payment gateway
The opposite of tokenization is detokenization, where a token is exchanged to retrieve the original sensitive data. Clover does not support any functionality to return the original credit card number or automated clearing house (ACH) information. Instead, we call our payment gateway, which handles the process of detokenizing the card in a secure environment and sends it to the credit card network for approval.
The following diagram illustrates the card flow for processing through Ecommerce API and the payment gateway. Card details are entered in the customer’s browser and are passed through Clover to TransArmor for tokenization. The token is then sent back to Clover. If you, the developer/app send in the token for processing, the token is then sent by Clover to the Payment Gateway, which will call TransArmor to detokenize the card before sending that card to the payment network for processing.
Types of payment card tokenization
Depending on where the card number is securely stored, there are three types of payment card tokenization.
- Merchant tokenization — Merchant collects the card number in clear, securely stores it, and assigns a new token identifier for the card number. The merchant can use the token to process payments without exposing the actual card number.
- Acquirer tokenization or security tokenization — Acquirer stores the card number in a token vault on behalf of the merchant. The acquirer can assign the scope of the token to a specific merchant or group of merchants. For example, TransArmor® Solution is an acquirer tokenization solution.
- Network tokenization or payment tokenization — Token service is provided by major card issuers such as Mastercard® and Visa®, in which the card number is stored in the token vault. The scope of these tokens can extend across acquirers. With network tokenization, the payment networks replace a primary account number (PAN) with a unique EMV® payment token that is restricted in its usage, for example, to a specific device, merchant, transaction type, or channel. Apple Pay® and Google Pay™ are types of network tokens.
TransArmor Solution: An example of acquirer tokenization
Clover uses the industry standard, TransArmor Solution by Fiserv. This product is a type of acquirer token to tokenize cards. TransArmor Solution protects payment card data from the moment a card is swiped, throughout the entire transaction process, incorporating several security and compliance products into one multi-layered, comprehensive solution.
Clover tokenization solution in two simple steps
Clover follows two steps process for handling payment cards:
Step 1: Tokenize the card
Clover API and iframe support encrypting the card number client-side using an RSA public key. Encrypted card number or ACH information is then securely transferred to the Clover PCI environment over the Transport-Layer-Security-encrypted (TLS-encrypted) channel and a token is returned for further processing. For additional security, a Clover-returned token is scoped by default for the merchant and the developer app that tokenized the card. The token cannot be used with another Clover merchant or app, even if the other app is made by the same developer.
See Clover Ecommerce basics for additional information.
Step 2: Use the token in Clover API
The Clover token returned in the first step can be used for payment processing.
Clover sends a token to TransArmor through the payment gateway for decryption and processing.
Single-pay versus multi-pay tokens
Clover tokens can be single-pay or multi-pay. Single-pay tokens can be used for a single payment like charge or pay for an order. Follow-up calls about payments like capture a charge or refund do not need a token because they are linked to the original payment transaction using a charge identifier returned in the original transaction response.
Multi-pay tokens, also referred to as card-on-file (COF) tokens, can be used more than once on calls like charge and pay for an order. Multi-pay tokens are created by associating a single-use token to a customer at creation or update, with a single-use token in the source field. Both card and ACH tokens can be converted to multi-pay tokens.
Card data security: Additional checks and measures
For security reasons, Clover does not validate payment card information while creating a token. It is the responsibility of developers to verify the token with a valid payment transaction when the token is charged. The save a card for future transactions tutorial provides more information on how to tokenize a card.
When tokenizing payment cards, developers are expected to store the last 4 digits of the payment card number to display along with the expiry date for reference. This information is especially useful to show the cardholder which card is stored on file.
For security reasons, Clover locks down the fungibility of multi-use tokens. Clover tokens are valid only in the Clover ecosystem; single-use or multi-pay tokens cannot be used with other Payment Service Providers (PSPs). These tokens are created based on the TransArmour token. Clover does not support tokens from other service providers, which means we cannot import tokens from other service providers. A token issued for one Clover merchant is not valid for other Clover merchants.
Clover multi-pay tokens may become invalid due to reasons like card number expiration, or if card is reported lost or stolen. Your app should not assume multi-pay tokens are valid. Developers are expected to process the payment on multi-pay tokens before delivery of products or services.
Conclusion
Tokenization is a powerful tool for ecommerce cards on file transactions. Understanding how and why they are used can help contextualize what makes them so versatile. Clover’s token scoping protects the merchant, customer, and app from bad actors taking advantage of tokens. Using these scoped tokens in iframe and hosted checkout integrations further reduces PCI burden for merchants and developers alike, ensuring safer transactions with less fuss.
