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, then the check status is changed to Canceled, but the payment remains in the database for the customer to view as a canceled 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, then 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, then the 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 have passed, then the pmtCheckUpdate job changes the status of the check from Processed to Paid.
- If the payment gateway returns the check, then the pmtCheckUpdate job updates the check 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, then the pmtCheckUpdate job 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 Standard Entry Class (SEC) codes are supported for ACH:
- Web. Internet Initiated Entry. This is the default.
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 using ANSI ASC X12 standards. Can be used either with the credit or debit application.
ACH Change Codes
Table 66 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.
Table 66. ACH Change Codes
|
|
C01 |
Incorrect DFI Account Number |
C02 |
Incorrect Routing Number |
C03 |
Incorrect Routing Number and Incorrect DFI Account Number |
C05 |
Incorrect Transaction Code |
C06 |
Incorrect DFI Account Number and Incorrect Transaction Code |
C07 |
Incorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code |
Additional information about these and additional ACH change codes are available from www.nacha.org. ACH Return Codes
Table 67 lists some of the ACH return codes that can appear in the returns file after running the pmtCheckUpdate job.
Table 67. ACH Return Codes
|
|
R01 |
Insufficient Funds |
R02 |
Account Closed |
R03 |
No Account or Unable to Locate Account |
R04 |
Invalid Account Number |
R05 |
Reserved |
R06 |
Returned for each ODFI's Request |
R07 |
Authorization Revoked by Customer. These are adjustment entries. |
R08 |
Payment Stopped or Stop Payment on Item |
R10 |
Customer Advises Not Authorized: Item Is Ineligible, Notice Not Provided, Signatures Not Genuine, or Item Altered. These are adjustment entries. |
R11 |
Check Truncation Entry Return (Specify) or State Law Affecting Acceptance of PPD Debit Entry Constituting Notice of Presentment or PPD Accounts Receivable Truncated Check Debit Entry |
R12 |
Branch Sold to Another DFI |
R14 |
Representative Payee Deceased or Unable to Continue in that Capacity |
R15 |
Beneficiary or Account Holder (Other Than a Representative Payee) Deceased |
R16 |
Account Frozen |
R17 |
File Record Edit Criteria (Specify) |
R20 |
Non-Transaction Account |
R21 |
Invalid Company Identification |
R22 |
Invalid Individual ID Number |
R23 |
Credit Entry Refused by Receiver |
R24 |
Duplicate Entry |
R29 |
Corporate Customer Advises Not Authorized |
R31 |
Permissible Return Entry (CCD and CTX only) |
R33 |
Return of XCK Entry |
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, then all the DDNs must use the same template. If you need to use different templates, then contact Oracle Professional Services about creating a custom class.
|