Administration Guide for Oracle Billing Insight > Command Center Jobs and Configuration Parameters > Payment Jobs >

pmtCheckUpdate Job

The pmtCheckUpdate job updates a check's status according to the response from the payment gateway. All files that match the necessary criteria are processed and moved to a history directory under the input directory. This job examine the check_payments table changes the status to Paid of any checks that meet the following criteria:

• Status is Processed
• Pay date is five or more days old
• Not returned

After the job completes processing, it moves all the processed files to a history directory under file input directory.

There are no configuration parameters for the pmtCheckUpdate job.

Automated Clearing House (ACH) Payment Gateway Logic

The pmtCheckUpdate job processes return files from the ACH, which can include checks from multiple DDNs, or applications. The job compares the immediate origin (routing number of the ODFI), immediate destination, immediate origin name, and immediate destination name in the ACH File Header to the same fields that are configured for the ACH. If the names are the same, then the pmtCheckUpdate job continues processing the ACH return file. If the names are not the same, then the job ignores the check.

The order of Immediate Destination and Immediate Origin can be swapped in the ACH return file from what the ACH specification recommends and the pmtCheckUpdate job will still process the file correctly.

For each Batch Header record, pmtCheckUpdate matches the Company Name and Company ID against the payment gateway definition. If there is a match, then pmtCheckUpdate uses the payment setting of the current DDN used to process this batch. If either the Company Name or Company ID does not match the payment gateway definition, then the pmtCheckUpdate job searches the Payment Settings of all DDNs. If the job finds a DDN setting with the same immediate information and company information, then it uses that setting to process the checks in that batch. If the job cannot find a match, then it raises an exception and the job fails.

For each successful batch header record match, the pmtCheckUpdate job updates the status according to Table 37.

The pmtCheckUpdate job also updates the status to Paid if there is no return from the ACH after the configured number of days. In the configuration settings for an ACH payment gateway you can change the number of days to wait after the pay date.

TIP:   If pmtCheckUpdate will be processing ACH return files containing multiple DDNs, then the Payment Settings for each payment gateway must have the same immediate origin and immediate destination. Also, each payment gateway used by those DDNs must use the same ACH template files, according to the ACH Template Directory parameter.

About ACH Return Types

One ACH return file can have three kinds of returns:

• Check returns
• NOC returns
• Prenote returns

For check returns, the corresponding check in the check_payments table is identified by either payment ID or gateway payment ID. The check status is updated to Returned, and the txn_err_msg field is set to the return code.

Table 38 lists the columns that are updated in the check_payments table after a check return is processed.

For prenote returns, the corresponding prenote check in the check_payments table is identified by either payment ID or gateway payment ID. The prenote's status is updated to prenote_returned, and the txn_msg_err column is set to the return code. From the prenote check, the payer_id, which is the user_id column in the payment_accounts table, is used to update payment enrollment information. The payment account with the same user ID and payment account number will be updated to bad_active in the account_status column, and txn_message is set to the ACH return code.

Table 39 lists the columns that are updated in the payment_accounts table after a prenote is processed.

NOC Returns

For NOC returns, the corresponding check, which can be either regular or prenote, is identified by either the payment ID or the gateway payment ID. The NOC's payer_id identifies the corresponding account. The Payment module matches it with the user_id column in the payment_accounts table.

If the auto update flag Update Payment enrollment in Case of NOC field was set to true, or Y in the Payment Settings, then the corresponding payment routing number, account number, or account type is updated dependent on the NOC code. If the flag is false, or N, then the current payment account information is not changed. In either case, the txn_message column populates with the format

NOC_CODE::NEW_ADDENDA_INFO::OLD_ADDENDA_INFO

where:

• NOC_CODE is the returned NOC code.
• NEW_ADDENDA_INFO is the correct NOC information returned from the ACH. This is the content from position 36 to 64 of the addenda record, with white spaces trimmed.
• OLD_ADDENDA_INFO is the existing or incorrect addenda information with the same format as new_addenda_info and is calculated on current payment account information.

The notify_status field is set to N if Notify NOC flag is set to Y in Payment Settings. If Send Email Notification in Case of NOC is set to Y in Payment Settings, then the notify_status field is set to N. The Payment module keeps both the old and new payment account addenda information, which allows pmtCheckUpdate to send an email containing both the old and new account information.

Table 40 lists the columns that are updated in the payment_accounts table after a NOC is processed.

ACH Return File Format

The ACH return file must not include new lines at the end of each record. To ensure that the ACH return files process correctly, the information listed in Table 41 must return correctly.