Implementation Guide for Oracle Self-Service E-Billing > About Payment Processing > About Check Processing >

Adding a Check Account

This topic is one example of adding a check account. You might use this feature differently, depending on your business model.

The following actions describe the process to enroll a new user with Oracle Self-Service E-Billling Payment who specifies a check account at enrollment time.

To add a check account for a new user

1. A new customer enrolls for check payment services by completing an enrollment form in the user interface. Oracle Self-Service E-Billling saves the information in the payment_accounts table with an enrollment status of pnd_active.
2. The pmtSubmitEnroll job runs to submit the enrollment information to the payment gateway. It changes the enrollment status to pnd_wait. If the check cannot be submitted, its status is changed to Failed.

   For ACH only, pmtSubmitEnroll sends customer enrollment information, which is contained in a zero amount check called a prenote, to an ACH payment gateway for verification. To send a prenote, the pmtSubmitEnroll job creates a zero amount check with status of prenote_scheduled, and immediately inserts the check into the check_payments table with a status of prenote_processed. This means that the status prenote_scheduled is transitory, and so is not visible in the check_payments table. A summary report is created, which can be viewed from the Command Center.

3. After receiving the customer enrollment information, the ACH payment gateway responds with a return file only if there are errors in the customer enrollment information. If there are no errors, ACH does not send a return file, or any other form of acknowledgement.
4. The pmtConfirmEnrollment job runs. This job updates the status of the customer enrollment status to active if there are no problems after a specified number of days (by default, three days).

   If the payment enrollment information is not correct, the pmtConfirmEnrollment job updates the customer enrollment status to bad_active. An exception report is created, which can be viewed from the Command Center.

5. The customer might optionally receive an email about enrollment status from the pmtNotifyEnroll job.

Check Account Enrollment Status Workflow

Figure 6 shows the status changes that a new check account goes through for enrollment, depending on customer actions and the pmtSubmitEnroll and pmtConfirmEnroll jobs. The status is kept in the account_status field in the payment_accounts table.

Figure 6. Check Account Enrollment Status Workflow

Table 52 describes each new check account status.

Check Payment Transaction Workflow

Check Payment Transaction Workflow, shown in Figure 6, processes the typical ACH check payment transaction cycle (excluding transfers between the ODFI, ACH operator and RDFI).

Figure 7. Check Payment Transaction Workflow

Workflow Description. This workflow performs the following actions:

1. A customer logs in and schedules a new payment. This step 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.

2. The pmtCheckSubmit job runs. This step 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 Oracle Self-Service E-Billling Payment database.

   If the check cannot be submitted, the status is changed to Failed. A summary report log file is generated, which can be viewed from Command Center.

3. The payment gateway (ODFI) processes the received check payment through the ACH operator to the RDFI. In this step, 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 Oracle Self-Service E-Billling.
4. The pmtCheckUpdate job runs. This step changes the status of the check from processed to paid if there is no return code, and five business days (default) have passed.

   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.

5. If configured, the pmtPaymentReminder job sends email to the customer about the status of the check payment.

Check Payment Status Workflow

Check Payment Status Workflow updates the check payment status at different stages of check payment processing.

Figure 7 shows the states that a check can be in, and the jobs that change the state.

Figure 8. Check Payment Status Workflow

Table 53 lists the statuses that can occur during a check payment transaction cycle. The values in parentheses () are the values saved in the Oracle Self-Service E-Billling Payment database.