Administration Guide for Oracle Self-Service E-Billing > Configuring Jobs > Payment Job Types >

Configuring a 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) Logic

The pmtCheckUpdate job processes return files from ACH, which can include checks from multiple DDNs. 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 payment gateway. If they are the same, pmtCheckUpdate continues processing the ACH return file. If they are not the same, check is ignored.

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 they match, then pmtCheckUpdate uses the payment setting of the current DDN used to process this batch. If either one does not match, pmtCheckUpdate searches the Payment Settings of all DDNs. If it finds a DDN setting with the same immediate information and company information, it uses that setting to process the checks in that batch. If it cannot find a match, it raises an exception and the job fails.

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

The pmtCheckUpdate job also updates the status to Paid if there is no return from 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 (ACH Template Directory parameter).

ACH Return Types

One 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 24 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 then 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 (account_status column) and txn_message is set to the ACH return code.

Table 25 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 (Y in the Payment Settings, then the corresponding payment account information (routing, account number or account type) is updated based on the NOC code. If the flag is false (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 ACH (content from position 36 to 64 of 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 notify_status 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 26 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 27 must return correctly.