Tokenization for recurring billing or repeat sales

Tokenization is now offered for resale of variable sales amounts. Enter card data one time only via PCI Compliant interface. The system will generate a token for you. To process future transactions, enter the TOKEN instead of card data, which can never be seen again.

The card data is encrypted and is never stored on your servers or computers. The token, which is worthless to others, is your way to submit future billing requests.

Tokenization and PCI DSS (payment card industry data security standards). PCI compliance is streamlined with tokenization and our end-to-end encryption solution.

The average user will submit cardholder data via the virtual terminal RESALE function. A token is automatically generated which you then store offline. To rebill, simply submit the token in lieu of the actual card number.

TYPICAL REPEAT SALE SET UP FOR RETAIL ENVIRONMENT:

– Merchant has customer fax a standard approval form with card data.

– The paper is filed in a locked drawer with limited personnel access. CVV is never stored.

– Merchant retrieves the information and key enters the transaction on a virtual terminal or desktop terminal when they need to rebill the customer.

– Merchant prints receipt and mails or faxes to the client.

TYPICAL REPEAT SALE SET UP FOR RETAIL ENVIRONMENT WITH CENPOS AND CARD IS NOT PRESENT:

– Merchant has customer fax a standard approval form listing the last 4 digits of the card only,  an email field, and with language about opting-in to receiving email from the merchant.

– Merchant gets card data over the phone and directly enters it into the secure virtual terminal using the RESALE button.

– Merchant copies the TOKEN  generated onto the merchant approval form which is then stored, in a locked drawer with limited personnel access.

– Merchant retrieves the token and key enters the transaction details on a virtual terminal or desktop terminal when they need to rebill the customer.

– Merchant uses the automated email function to send the customer a receipt, or prints receipts the old way.

What if the customer is in the store for the first order, but then won’t be there later when you bill more? You’ll swipe the card as usual, using the resale button. The cashier will be prompted for address and other data as if the customer is not present.

The first transaction will process via your retail swipe account. The future card not present transactions will process via your MOTO account, automatically, when you key enter the transaction later. This is a significant competitive product difference from any other solution you may looked at.

  1. Merchants will qualify for the best interchange rate for each type of transaction, thereby lowering costs.
  2. Merchants will meet the card association requirements for proper presentment to reduce risk of chargebacks from disputes. (Different rules apply about data submitted and signatures on swipe vs moto.)
  3. Both transactions will be in a fully PCI Compliant environment, reducing risk of liability from improperly protecting card data.
  4. Cashiers are removed from any decision making that can affect your rate qualification in every transaction. The system will automatically prompt for data needed based on transaction parameters.
  5. Best of all, no terminal progamming updates! The hosted solution is always current and any terminal connected is simply a slave of the system.

Because they have no meaning by themselves, tokens or aliases are useless to criminals if your customer hard copy files were compromised. Per the PCI DSS standards for your organization, you’ll need to have your workstations scanned that you enter transaction on.

Ideal solution for any B2B companies with corporate customers. Sign up for RSS for more details on this feature. For a demo, call the hotline at the top of this web page.

Related articles: Can you store track data and be PCI Compliant?
Storing CVV codes so you can rebill