CCP610 – Credit Card Settlement Process

This batch process settles credit card payments and refunds for organizations using Payflow Pro (VeriSign), CyberSource, or Vantiv (new as of 7.6.0) as their credit card payment handler.

When a credit card or PayPal account (as of 7.6.1) is used as the payment method for an order, the system retrieves an authorization for the credit card. Afterwards, in order to settle the credit card transaction for the order, CCP610 must be run.

CCP610 is usually run on a daily basis and at the end of the day.

In the case of credit cards or PayPal accounts used for payment, settlement is the process by which funds are collected from customers and transferred to the merchant (i.e., the organization that made the sale). In the case of refunds, settlement is the process by which funds are transferred from the merchant to the customers getting refunds.

Typically, credit card payments are settled on the same day as the authorization. The exception to this is if credit cards payments are used for inventory product orders. Credit card payments for inventory products are settled when the product ships to the customer. When an inventory product order is placed, Personify retrieves the credit card authorization and creates a deferred receipt record in the Order_Deferred_Receipts table. After the product ships and the next time CCP610 is run, CCP610 automatically deletes the deferred receipt record, creates a receipt record in its place, and then settles the credit card payment. If the credit card authorization is rejected (e.g., due to insufficient fund, etc.), then the receipt is reversed and that transaction will display on the CCP610 error report.

As of 7.6.1, for organizations using Vantiv as their payment handler, CCP610 checks the PROCESS_EXPIRED_CC merchant parameter to determine whether expired credit cards should be selected for processing. If the parameter is set to "Y", CCP610 will transmit credit card payments to Vantiv even if the credit card is expired. When Vantiv returns the authorization request response, if the organization is using Vantiv’s "Account Updater" service, the response file will include the updated credit card expiration date, as well as any other changes that may have been made to the credit card, such as change of name, change of credit card number or change of credit card type.

When a deferred receipt is reversed and a second deferred receipt is taken, CCP610 will make the deferred receipt zero; a positive deferred receipt will never exist.

When a credit card is used for payment and an authorization is received, a record is created in Personify360 in the CCP_Req_Ans table with “Approved” set to Y and a “Request Type” code of either PRE-SALE (for non-inventoried orders) or PRE-AUTH (for all inventoried orders that have not shipped). The “Request Type” code MANUAL-AUTH indicates that the credit card requires manual authorization. When CCP610 settles the credit card payment, it creates a new record with a “Request Type” of SALE.

For the CCP610 batch process to settle deferred credit card payments for inventory product orders that have shipped, a direct batch must be defined in the “Deferred CC Batch” parameter. A batch is required when creating receipts in Personify360. If a direct batch is not entered for this parameter, CCP610 will not process deferred credit card payments for inventoried product orders that have shipped. If a batch is selected, CCP610 will close the batch at the end of the CCP610 run.

When a credit card payment is refunded, a record is created in the CCP_Req_Ans table with a “Request Type” code of PRE-CREDIT. When CCP610 settles the credit card refund, it creates a new record with a “Request Type” of CREDIT. 

CCP610 sets the settlement number on all successfully settled credit card transactions to a positive number that represents the date the transaction was settled. The settlement number for any transactions settled between January 1 and September 30 is a 7-digit number in mddyyyy format. For example, the settlement number for transactions settled on March 7, 2010 would be 3072010. The settlement number for transactions settled between October 1 and December 31 is an 8-digit number in mmddyyyy format. For example, the settlement number for transactions settled on November 7, 2010 would be 11072010.

If the credit card transaction was not successfully settled, the settlement number is set to a negative number that represents the date the transaction was attempted to be settled.

If a transaction has a negative 1 as the settlement number, it means the credit card transaction was entered as a pre-settled transaction. Pre-settled transactions are ignored by CCP610.

Settlement numbers are set based on the date the transaction was settled, not on the run date of CCP610. If CCP610 runs a minute before midnight, it is very likely that some transactions will settle after midnight, meaning that they would get a different settlement number. Therefore, it is highly recommended to run CCP610 no later than 11:55 pm.

Additional Information

The following includes additional caveats or options for CCP610.

·            A parameter is also provided for CCP610 to optionally void authorizations for credit card payments not linked to an order. Credit card payments created through Rapid Donation Receipt Entry are not voided because donation orders and receipts are not created until the FND640 batch process is run.

·            To avoid potential data corruption problems, system logic exists to prevent multiple runs of CCP610 from being run concurrently.

·            For organizations using PayPal as their payment handler, CCP610 also updates the credit card token and token date on the customer’s Cus_Credit_Card_Profile record for the credit card.

Best Practices

For more information, please see Daily Financial Reporting Best Practices - Credit Card Settlement.

Parameters

CCP610 does not provide the ability to add additional filters and is always run in PROD mode.

Sample Report

CCP610 - Credit Card Settlement Process

This report lists all transactions captured by the CCP610 process. The transaction type is based on the type of transaction it was when CCP610 picked it up. After the process completes, all pre-sales become sales. If you ran CCP610 again during the same day, the transactions you originally saw as pre-sales would display as sales in the new report.

Five different types of transactions types exist for credit card processing:

·            Pre-Sale – transactions waiting for settlement.

·            Sale – transactions already settled.

·            Pre-Auth – Inventoried product deferred receipt.

·            Pre-Credit – refunds waiting for settlement.

·            Credit – refunds already settled.

CCP610 - Authorization Deferred Receipts

This report displays both the New Receipt number and the Old Receipt number so users can cross-reference the new receipt to the original deferred receipt.