Discharging transactions—Default process

📘

A new Discharge and Payment Hierarchy architecture is available in the EXT environment. This guide will be superseded by the Discharging transactions guide as soon as the new architecture becomes available in production.

The discharge process defines how cardholders' payments are applied to transactions to reduce their debt. When a credit transaction occurs, its value is deducted from the balances of one or more debit transactions. When a debit transaction is fully discharged, it's said to be paid in full or paid off.

The Pismo platform runs the discharge process on the following occasions.

• When the platform receives a credit transaction: In this case, the discharge process finds all the debit transactions with a balance due and begins paying them off one by one, until the money from the credit transaction is used up. If the amount of the received credit is greater than the total debits, the residual credit amount is carried over until the next time a credit is received (which triggers the discharge process again) or until cycle closing (which also triggers the process).
• Immediately before closing the credit cycle: In this case, the discharge process continues paying off the unpaid debit transactions for the closed cycle using the residual credit amount (if any).

🚧

In times of high load, there could be a delay before a payment is used to discharge transactions. You should take this into account when designing your credit program.

Payment hierarchy

The payment hierarchy is the set of rules that the Pismo platform uses to determine the order in which unpaid transactions are paid off by the discharge process. These rules ensure that overdue transactions are paid off first.

The payment hierarchy divides transactions into these groups:

• Group 1—Overdue transactions
• Group 2—Transactions from the previous cycle that are not yet overdue
• Group 3—Transactions from the current credit cycle

Group 1 transactions are fully discharged first, then group 2, and finally group 3.

📘

As noted earlier, there are only two triggers for the discharge process.

• A new credit is received.
• The platform is ready to close the cycle.

So, if there is money left over from a credit after paying off all the debits, and another debit is received, the leftover money is not immediately used to discharge the new debit. But when a new credit is received, or the cycle is about to close, the discharge process is triggered, and the leftover money is then applied to the new debit.

Within each group, the order in which transactions are paid off is determined by their charge orders and their real due dates. For more information about the charge order, refer to Managing the charge order for debit transactions. The transactions within each group are paid off in the following order.

1. Transactions with the lowest charge orders, as defined in their associated program transaction types, are discharged first.
2. Transactions with the oldest due dates are discharged next.
3. Transactions with the lowest charge orders, as defined in their associated program transaction categories, are paid off next. (Charge orders configured in program transaction types override charge orders configured in program transaction categories.)
4. Any remaining transactions are discharged last, in the order of their transaction event dates. The transaction event date is the date on which the transaction occurred. It's returned in the event_date field of the Get transaction endpoint.

These rules provide the flexibility for you to configure how transactions are paid off within a group.

🚧

An exception to the above rules can occur when a purchase is canceled. When a cardholder makes a purchase, the resulting debit transaction has an authorization ID (authorization_id). If the purchase is canceled, this generates a credit transaction for the same amount and with the same authorization ID. In this case, the debit transaction has priority and is discharged before any other transactions.

In other words, when a credit transaction has the same authorization ID as a debit transaction, the debit transaction has priority over other transactions.

Applying the discharge process in a simple example

The following example shows how the discharge process works in the simplest case.

The cardholder makes a purchase:

Later, the cardholder makes a payment:

The Pismo platform performs a discharge. It deducts the balance of transaction 2 from the balance of transaction 1:

The balance for the payment transaction is $0.00. If the payment had been for more than $50.00, then the payment transaction would have been left with a non-zero balance. This remaining balance would be deducted from any future purchases.

Applying the discharge process in a more complex example

The following example shows how the discharge process works in a more complex case where the debit transaction is associated with a program transaction category.

Suppose you have a program transaction category that defines charge orders for fineable and non-fineable transactions as follows:

Suppose you have transaction types defined for purchase transactions and interest transactions and those types are associated with program transaction categories (via program transaction types) as follows:

Now suppose you have the following transactions:

When the account receives a credit, the Pismo platform discharges the transactions in the following order:

1. B (because A and B are in an overdue statement, but the category of transaction B has a charge order lower than the category of transaction A.)
2. A (because transaction A is in an overdue statement and transaction C is not.)
3. C