Distributing A Payment Event

The base-package, by default, creates a single payment for a payment event. Some business practices require potentially many payments to be created when payment events are added.

A few examples of when multiple payments may be necessary are:

• A payment amount needs to be distributed towards different distribution types:
  • $50 in interest
  • $60 in collection charges
  • $70 in taxes
• Each of the above distributions is realized as a separate payment identified by its own match type (i.e., there'll be one match type called Interest, another called Collection Charges, etc.).

In this example, the debt of a single service agreement may be relieved by each of these payments.

• In a similar way, you may want to create a separate payment for an overpayment to differentiate it from regular payments (using yet another match type).
• In the case of a social service agency that pays for many accounts, a single payment event may be distributed amongst multiple accounts.

The method by which a payment amount is distributed to create payment(s) is contained in Create Payment algorithms plugged in on a distribution rule.

There is yet another aspect to having control over how payment events are created. The default method of creating payment events assumes knowledge of account IDs (of the payor and the payee) when making a payment. In cases where payments are made by and towards business entities other than accounts, knowledge of their corresponding account IDs may not be available at payment time. Consider the following examples:

• A payment is made to pay a person's bill, providing the person's identification at payment time.
• A payment is made towards a specific service agreement using a "contract number" defined as SA characteristic.

The method by which the tender account is determined by means of an alternate identifier is contained in Determine Tender Account algorithm plugged in on a distribution rule.