11 Handling Atypical Payments

This chapter describes how to handle payments that are not tailored to your normal payment processing.

For more information on payments, see the following documents:

Handling Overpayments and Underpayments

If a customer pays too much or too little, your Oracle Communications Billing and Revenue Management (BRM) business policies may require payment allocation. See "About Allocating Payments".

  • For underpayments, choose which bills or items to allocate the payment to.

  • For overpayments, pay all items and generate a credit balance.

By default, BRM requires overpayments to be allocated.

To change the default BRM behavior for overpayments and underpayments, customize the PCM_OP_PYMT_POL_UNDER_PAYMENT or PCM_OP_PYMT_POL_OVER_PAYMENT policy opcodes.

If the money received is more or less than the sum of the total due of all the open items selected by PCM_OP_PYMT_SELECT_ITEMS, PCM_OP_PYMT_SELECT_ITEMS calls PCM_OP_PYMT_POL_OVER_PAYMENT or PCM_OP_PYMT_POL_UNDER_PAYMENT, respectively. PCM_OP_PYMT_SELECT_ITEMS does not call these policy opcodes if:

  • The amount is equal to the sum of the total due.

  • The flag PIN_BILLFLG_SELECT_FINAL is passed in.

  • The flag PIN_BILLFLG_DEFER_ALLOCATION is passed in.

By default, PCM_OP_PYMT_POL_OVER_PAYMENT returns the amount overpaid on the output flist. The excess amount remains in the bill unit specified on the input flist (or the default bill unit if none was specified) until they are manually redistributed by using Customer Center. You can customize PCM_OP_PYMT_POL_OVER_PAYMENT to perform as a hook for an application that would search for and settle all overpaid payment items.

By default, PCM_OP_PYMT_POL_UNDER_PAYMENT pays the billed items in order they are listed on the input flist (item[0] first, then item[1], item [2], and so on). It then returns the items paid on the output flist. Items that are partially paid are returned with a new amount due. Items not paid are not returned.

Handling Late or Missed Payments

You can specify how BRM handles late or missed payments, for example, change the account status to inactive or charge a late fee.

To change the account status, customize the PCM_OP_PYMT_POL_COLLECT policy opcode.

To charge a late fee, customize the PCM_OP_PYMT_POL_APPLY_FEE policy opcode.

Handling Multiple Payments to the Same Account

By default, you cannot use Payment Tool to apply more than one payment from a batch to a single account. However, if the account uses open item accounting, you might need to apply more than one payment to more than one bill.

To enable Payment Tool to apply multiple payments from the same batch to a single account, you edit the PaymentTool.ini file.

See "Applying Multiple Payments to the Same Account".

Applying Multiple Payments to an Account through Payment Gateways

The PCM_OP_PYMT_COLLECT opcode enables a payment gateway to apply multiple payments from the same batch to a single account. Payment gateways need no additional configuration to enable this feature.

To avoid payment allocation errors when a batch contains multiple payments for the same account, the PCM_OP_PYMT_COLLECT opcode processes them sequentially: that is, it performs all operations on one payment before moving on to the next payment. For example, a batch contains two payments for the same account: payment 1 = $10 and payment 2 = $20. The account has three open bill items: item 1 = $5, item 2 = $3, and item 3 = $22. Hence, the total payment amount ($30) is equal to the total due amount ($30) of all the items. The PCM_OP_PYMT_COLLECT opcode allocates the payments as shown in Table 11-1:

Table 11-1 PCM_OP_PYMT_COLLECT Payment Allocation

Operation/Remaining Total Due for Open Bill Items Item 1 Item 2 Item 3

1. Select items for payment 1 ($10).

Beginning with the oldest open item (item 1), BRM selects items in chronological order until the payment is completely spent.

$5

$3

$22

2. Apply payment 1 ($10):

$5 to Item 1

$3 to Item 2

$2 to Item 3

$0

$0

$20

3. Select items for payment 2 ($20).

Because payment 1 has been applied, the two oldest items selected in step 1 are now paid and closed, and the amount due for item 3 has been reduced to $20.

$0

$0

$20

4. Apply payment 2 ($20):

$0 to Item 1

$0 to Item 2

$20 to Item 3

$0

$0

$0

For information about payment gateways, see "About Payment Gateways".

Handling Failed Unconfirmed Payments

An unconfirmed payment is an BRM-initiated payment that is posted as successful in BRM before receiving a confirmation from the bank or payment processor, for example, an automated clearing house.

If the bank or payment processor later sends a failure notification for a BRM-initiated payment (for example, due to insufficient funds or an expired credit card), BRM reverses the initially-successful payments and posts the failed payments.

Failed unconfirmed payments can be submitted to BRM by using a payment gateway, or by using Payment Tool or another third-party payment application.

Figure 11-1 shows how failed unconfirmed payments are processed with an automated clearing house (ACH). Each step in the process is described below.

Figure 11-1 ACH Processing of Failed Unconfirmed Payments

Description of Figure 11-1 follows
Description of ''Figure 11-1 ACH Processing of Failed Unconfirmed Payments''

  1. The Connection Manager (CM) collects the balances due on accounts and sends the charges to the Data Manager (DM) for processing.

    /event/billing/charge/pay_type events are recorded in BRM.

  2. The Data Manager (DM) processes the charges and sends them to the ACH.

  3. Before charges are confirmed by the ACH, the DM automatically sends them back to the CM as successful payments.

    /event/billing/payment/pay_type events are recorded in BRM.

  4. The ACH returns any failed unconfirmed payments in a failed payment file. The failed payment records must include the transaction ID, payment failure reason code, and result.

  5. The failed payment file is loaded into Payment Tool or a third-party payment application.

  6. The transaction ID, reason code, and result are validated, the failed payments are recorded, and the unconfirmed successful payments are reversed.

    Failed unconfirmed payments are recorded as /event/billing/payment/failed events, and the reversals of the initially-successful payments are recorded as /event/billing/reverse/pay_type events.

    Note:

    Both the /event/billing/payment/failed event and the /event/billing/reversal event contain the same transaction ID of the original unconfirmed payment.

When a unconfirmed payment fails, the failed payment is recorded in BRM with a balance impact of 0, and the successful payment amount is re-applied to the account balance.

To charge fees for failed unconfirmed payments, see "Configuring Payment Fees".

Submitting Failed Unconfirmed Payments with Payment Tool

Failed unconfirmed payment records are sent to BRM in a batch containing only failed payments. When you open the failed payment batch in Payment Tool, payments are displayed with a failed payment status.

You process failed payments the same way you process other payment batches. See "Processing a Batch of Payments by Using Payment Tool".

Requirements for Posting Unconfirmed Payments

Failed unconfirmed payments are processed by the PCM_OP_PYMT_COLLECT opcode. The interface you use to load failed payments into the BRM database must be configured to send the following information with each failed payment to be validated in BRM:

  • Transaction ID

  • Failed payment status

  • Failure reason ID

The transaction ID of the failed payment is compared against the transaction ID in the /event/billing/payment/pay_type object of the initial unconfirmed payment that was posted successfully in BRM.

If the transaction IDs are the same, the original payment is reversed and the failed payment is recorded. If the transaction ID is missing or incorrect, or the successful payment cannot be located in the database, the PCM_OP_PYMT_VALIDATE_PAYMENT opcode returns a value of PIN_PYMT_FAILED in the PIN_FLD_RESULT field, and an error is displayed. The payment is not reversed and the failed payment is not allocated. You must manually fix the transaction ID to resubmit the payment. Or, you can configure BRM to identify the original payment by using other payment attributes. See "Customizing Payment Fees".

Customizing Unconfirmed Payment Processing

When a failed unconfirmed payment is received, the original successful payment is identified by using its transaction ID.

The PIN_FLD_PAYMENT_TRANS_ID field in the /event/billing/payment/failed event must be equal to the PIN_FLD_TRANS_ID of the successful unconfirmed payment item. If so, the unconfirmed payment is reversed and the failed payment posted to the proper account.

If the payment processor is not able to send a transaction ID with each payment, or if the transaction ID is not a reliable means of identifying a payment, you can configure PCM_OP_PYMT_POL_VALIDATE_PAYMENT to find the original unconfirmed payment by using other payment properties. For example, you can use a combination of the payment amount, account number, and invoice number.

When the payment is received, BRM compares these values in the failed payment with those of the original unconfirmed payment, and if the values match, it will reverse the unconfirmed payment and post the failed payment.

Note:

The result of the validation is the POID of the unconfirmed successful payment item that was recorded in BRM. If the item is not available, the reversal cannot occur. By default, this policy opcode retrieves the item by finding the payment event with corresponding transaction ID.