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

About Recurring Payment Processing

Oracle Self-Service E-Billing provides two types of recurring payments for check and credit card:

• A recurring payment. A recurring payment allows a customer to schedule a payment amount that is fixed, for the entire amount due from a bill, or for the minimum amount due from a bill. The payment can be scheduled to be paid on a certain date of the week, month or quarter.
• An automatic payment. An automatic payment allows a customer to schedule a payment of a fixed amount, for the entire amount due from a bill, or for the minimum amount due from a bill, to be made a certain number of days before due date. Automatic payments of the entire amount due can also be made, if the amount due is less than a specified amount.

Both recurring and automatic payments are designated as recurring payments by the NACHA 2009 specification. NACHA 2009 defines a payment as recurring when the account manager (Oracle Self-Service E-Billing) keeps the account information in a database.

Recurring payments can be modified or cancelled at any time before the payment is scheduled.

Recurring payment allows a customer to make payments automatically, based on the amount and pay date. There are five kinds of recurring payments:

• (Minimum) amount due and before due date, for example, pay the entire amount due two days before the due date.
• (Minimum) amount due and fixed pay date, for example, pay minimal amount due on day 31 of each month.
• Fixed amount and before the due date, for example, pay $100 one day before the due date.
• Fixed amount and fixed pay date, for example, pay $100 on the first day of each month.
• (Minimum) amount due up to a fixed amount, and send email if over that fixed amount.

Amount defines how much the recurring payment is going to pay for each payment. The amount can be fixed, amount due or minimum amount due. If the amount is (minimum) amount due, then it must be indexed by the Composer. The name and format of the (minimum) amount due must be specified in the Payment Settings topic of the Command Center.

Pay date defines when each payment is going to be cleared (money transfers). The pay date can be a fixed date or a date before it is due. If it is a before due date, then the due date must be indexed by the Composer. The name and format of the due date must be specified in the Payment Settings topic of the Command Center.

For monthly payments, if day 29, 30, or 31 is selected, and that day does not exist for a particular month, then the pay date defaults to the last day of that month. For example, specifying day 31 of each month ensures that payments are made at the last day of each month.

For weekly payments, the week starts on Sunday. For example, day 1 of each week means Sunday.

The effective period defines when a recurring payment starts and ends. A payment is made if its pay date is within the effective period (inclusive). If the pay date is after the end date of the effective period, then the recurring payment is deactivated. By default, a recurring payment only starts tomorrow. This is done so that all bills that arrive up to and including today are considered paid, so recurring payment must not pay these bills a second time.

Each bill as a unique ID called the bill ID. In the Command Center, the bill ID is the doc ID.

There is also a script that can be run after installation that prevents a bill from being paid twice. For more information about that script, see Installation Guide for Oracle Self-Service E-Billing.

After a user creates a recurring payment, that user is not permitted to change the payment amount from fixed to (minimum) amount due, or to change the pay date from fixed to before due date, or conversely. When a recurring payment starts (which is when the first recurring payment has been made), the start date of the recurring payment cannot be modified.

CAUTION:  Recurring payment supports only one customer account for each biller. Recurring payment does not support multiple customer accounts with a single biller.

Recurring payments consist of actions at the front-end (UI) and back end (Command Center jobs). The UI allows a user to insert, update, and delete a recurring payment, and the back end pmtRecurPayment job makes the payment.

The recurring payment feature is very complex and involves a great deal of business logic.

Recurring Payment Assumptions

The recurring payment feature assumes that the bill balances are accumulative. The bill for this billing cycle includes the balance of the bill from previous billing cycle, and the later bill has a due date after that of the previous bill (the only situation where the same due date can happen is for a rebill).

Recurring payment also assumes that each bill has a date indicating the chronological order of bills. This is usually the date when the bill arrives. For example, in the case of the Command Center, the Doc Date can be used to indicate the chronological order of arriving bills. In the case of external billing software, other dates such as statement date can be used for this purpose. When recurring payment synchronizes with the Command Center or other billing software, it must retrieve the latest bill issued between the last_process_time and current time. This chronological date of bills (Doc Date or statement date) is used to guarantee that functionality.

Negative and Zero Bill Amounts

If a bill has a negative balance, then no payment is made. Instead, recurring payment assumes that this credit will roll into the balance of next bill. However, a zero dollar payment will be made if the balance is zero.

Due Dates

If a recurring payment is not a fixed date and fixed amount, then it must have a due date. The due date is used to decide which bill is the latest one to pay. For the Command Center, you must index the due date or some date equivalent to use as the due date.

Using Billing Software Other than the Command Center

You can use billing software other than Recurring payment assumes nothing specific to the Command Center and the only action to take is to reimplement the IBillDepot API. The billing software must meet assumptions stated in Recurring Payment Assumptions.