Vantiv Tokenization

For organizations that are currently using CyberSource or Payflow Pro, but what to integrate with Vantiv, you must convert existing credit card tokens into tokens that can be consumed by Vantiv.

The tokenization service is REQUIRED for all clients using the Vantiv integration.

Vantiv can perform a bulk token registration on all the card numbers that were vaulted with your previous processor. The following is an example of the process:

1. During your implementation with Vantiv, contact your previous processor and request an encrypted mapping file containing the card and token numbers for your customers. A Vantiv implementation consultant will work with you and your previous processor to facilitate the secure transfer of this file without impacting your PCI compliance. The file can be comma-delimited, tab-delimited, or any other common format.

2. Vantiv performs a bulk token registration of all of the card numbers contained in the file.

3. Vantiv returns a mapping file to your organization containing the old tokens and the new Vantiv issued tokens, so that you can update your order processing system.

Vantiv supports token-extractor formats of all major token service providers. Contact your Vantiv implementation consultant for more information or to initiate this process.

The process for converting from one credit card processor to another is illustrated in the following diagram:

Pre-Requisite Requirements

Prior to uploading the re-tokenized customer credit card token data from Vantiv, organizations need to have activated Vantiv as a payment handler and updated Vantiv interface parameters in Personify360.

You also need to decide what approach you will follow with regards to receipt type codes. The two options to choose from are:

· Continue to use the same receipt type codes for Vantiv as the organization used for their previous credit card processor. This is the recommended approach if the organization does not need to continue to use their previous credit card processor to close out credit card transactions that are still pending. If this approach is selected, the organization will need to manually update the payment handler on all credit card and echeck receipt type codes from their previous payment handler to Vantiv and update the merchant ID on the GL cash account(s) linked to the receipt type. Note that, if the same receipt types will be used, If forced refunds are not allowed, refunds must be by check so no need to update PAYMENT_HANDLER_CODE or MERCHANT_ID on Far_Batch_Detail.

· Create new receipt type codes for Vantiv. This is a more involved approach, because typically there may be transactions originally created using the previous credit card processor (PayPal or Cybersource) that need to updated once the organization decides to strictly use Vantiv as their processor. If using new receipt type codes, staff do not need to manually change the payment handler and merchant ID on the existing receipt type codes; they just need to create new ones.

Logic for Updating Credit Card Data

The Personify360 process that will update an organization’s credit card data to use Vantiv tokens executes the updates listed in the chart below, whether the organization is using the same receipt type codes or using new receipt type codes:

Table.FIELD_NAME	Value to be Set	Comments
Cus_Credit_Card_Profile Updates
Cus_Credit_Card_Profile. PROFILE_REFERENCE	New token from Vantiv. Select new token from Vantiv where the old token in the Vantiv file matches the existing Cus_Credit_Card_Profile. PROFILE_REFERENCE value before the update.
Cus_Credit_Card_Profile. PROFILE_DATE	Date Vantiv created credit card data file with new token
Cus_Credit_Card_Profile. PAYMENT_HANDLER	"VANTIV"
Cus_Credit_Card_Profile. MERCHANT_ID	Process will have a variable for the merchant ID that will be updated to the MERCHANT_ID field for all "open" records in Cus_Credit_Card_Profile.
CCP_Req_Ans Updates
CCP_Req_Ans. ANS_TIMESTAMP	Set to be 1 year back (today minus 1 year)
Order_Deferred_Receipt Update
Order_Deferred_Receipts. DEFERRED_CC_AUTH_ EXP_DATE	Set to today minus one day	This will force all INV orders with deferred receipts to be reauthorized
Far_Batch_Detail Updates
Far_Batch_Detail. PAYMENT_HANDLER_CODE	(go back today minus one 1 year) “VANTIV”	This needs to be updated because Personify360 looks up payment handler info on Far_Batch_Detail on the receipt batch when refunds and adjustments are done; Personify360 does not look at the Far_Receipt_Type and Fgl_Cash_Account records (safer to do that) for the receipt type. If the Far_Batch_Detail. PAYMENT_HANDLER_CODE and MERCHANT_ID are not updated, then the organization will not be able to do refunds and adjustments. Note that, if forced refunds are not allowed by the organization, then refunds will need to be made by check, so there is no need to update PAYMENT_HANDLER_CODE and MERCHANT_ID on Far_Batch_Detail records.
Far_Batch_Detail. MERCHANT_ID	Process will have a variable for the merchant ID that will be updated to the MERCHANT_ID field.

The Personify360 process that will update an organization’s credit card data to use Vantiv tokens only executes the updates listed in the chart below if the organization is going to create new receipt type codes to be used with Vantiv transactions:

Table.FIELD_NAME	Value to be Set	Comments
Cus_Credit_Card
Cus_Credit_Card. RECEIPT_TYPE_CODE	Value for new RECEIPT_TYPE_CODE to be used for Vantiv transactions	Another option is to create new Cus_Credit_Card records but it’s easier to keep the same Cus_Credit_Card record.
Order_Detail_CC_Info
Order_Detail_CC_Info. RECEIPT_TYPE_CODE	Value for new RECEIPT_TYPE_CODE to be used for Vantiv transactions.