Administration Guide for Oracle Self-Service E-Billing > Payment Transactions > About Check Payment Transactions >

The Cycle of an ACH Check Payment Transaction

Figure 1 shows the entities in an ACH payment transaction.

Figure 1. Check Payment Transactions

A typical ACH check payment transaction cycle (excluding transfers between the ODFI, ACH operator and RDFI) is as follows:

• A customer logs in and schedules a new payment from the list of defined checking accounts. The Payment module in Oracle Self-Service E-Billing inserts a check into the database with a status of Scheduled.
• If the customer later cancels the payment, the check status is changed to Cancelled, but the payment remains in the database for the customer to view as a cancelled payment.
• The pmtCheckSubmit job runs, selects all the checks that are due for payment, creates a batch file of selected checks, and sends the batch file to the payment gateway (ODFI). It also changes the status of each selected check to Processed in the Payment database.
• If the check cannot be submitted, the status is changed to Failed. A summary report log is generated, which can be viewed from Command Center.
• The payment gateway (ODFI) processes the received check payment through the ACH operator to the RDFI. If there is an error clearing the check, ACH creates a file containing a code that indicates why the check was returned, and sends the file to the Payment module.
• The pmtCheckUpdate job runs. If there is no return code, and five business days (default) have passed, pmtCheckUpdate changes the status of the check from Processed to Paid.
• If the payment gateway returns the check, the pmtCheckUpdate job updates the check's status to returned, and saves the reason code in the txn_err_msg field of the check_payments table. An exception report is generated to summarize the information in the returned file, which can be viewed from Command Center.
• If there is an error other than returned, pmtCheckUpdate changes the check status to Failed.
• An ACH payment gateway might return an NOC in response to a prenote. For an NOC, the pmtCheckUpdate job reads the NOC and inserts a new zero amount check into the check_payments table with a status of noc_returned. The payment_accounts table might be updated, depending on the setting of auto-update for NOC in Payment Settings.
• If the pmtPaymentReminder job is configured, then it sends an email to the customer about the status of the check payment.

Supported SEC Codes

The following SEC Codes (Standard Entry Class Codes) are supported for ACH:

• Web. Internet Initiated Entry (default for the Payment module).

  Debit entries are originated (either single or recurring) from a customer's account using Web-based authorization.

• PPD. Prearranged Payment and Deposit Entry. Under PPD the following types are included:
  • Direct Deposit. The credit application transfers funds into the customer's account.
  • Preauthorized Bill Payment. Represents a debit application, where billers transfer electronic bill payment entries through the ACH network.
• CTX. Corporate Trade Exchange

  Supports multiple addenda record based on ANSI ASC X12 standards. Can be used either with the credit or debit application.

ACH Change Codes

Table 68 lists some of the ACH change codes (also known as NOC codes) that can appear in the returns file after running the pmtCheckUpdate job if previously valid payment information is now incorrect or out-of-date.

Additional information about these and additional ACH change codes are available from www.nacha.org.

ACH Return Codes

Table 69 lists some of the ACH return codes that can appear in the returns file after running the pmtCheckUpdate job.

Additional information about these and additional ACH return codes are available from

http://www.nacha.org/

NOC Transactions

When a prenote is returned with a NOC, TXN_MESSAGE is populated with NOC information formatted as NOC_CODE::NEW_ADDENDA_INFO::OLD_ADDENDA_INFO

where:

• NOC_CODE is the three-character code returned.
• NEW_ADDENDA_INFO is the NOC information returned from ACH, which can include the corrected account number, routing and account type.
• OLD_ADDENDA_INFO is the existing addenda information.

ACH Effective Date

The Skip nonbusiness days for batch effective entry date field on the Payment Settings page for an ACH check payment gateway controls how the effective entry date is calculated when the ACH batch file is created by pmtCheckSubmit.

If the field is set to Yes, then nonbusiness days are not taken into consideration. The effective entry date is set to the payment date that the customer specified when scheduling the payment.

If the field is set to No, then nonbusiness days are skipped, and the effective entry date is the next business day following the computed date. The Payment module checks the scheduled payment date to determine whether it is on or before the end of today. If it is, then the computed date is the customer-scheduled date plus one. If it is not, then the computed date is the customer-scheduled date.

Nonbusiness days are weekend days, plus the U.S. Federal holidays.

ACH Settlement Date

The ACH settlement date is not written to the ACH batch file by pmtCheckSubmit. That date is added by the ACH Operator when the payment is actually settled.

ACH Addenda Records

The Payment module supports ACH addenda records, which means you can append a list of addenda records after an entry detail record in an ACH file. Addenda records are biller-specific, so customizing is required to support this feature. Theoretically, you can put any information into an addenda record, for example, the invoices of a payment. To add addenda records, you must write a plug-in for the pmtCheckSubmit job. Contact Oracle Professional Services or your development team for more information about supporting ACH addenda records.

Multiple DDNs in ACH Files

If you put multiple Document Definition Names (DDNs) in one ACH file, all the DDNs must use the same template. If you need to use different templates, contact Oracle Professional Services about creating a custom class.