In a Full balance credit program, the Pismo platform provides card management and authorization integration with your card network. It also manages your customers’ balances and credit limits.

In a credit program, accounts are post-paid. This means that a cardholder can charge as much to their card as they like as long as the card balance remains below their credit limit. For each account, a statement is issued periodically showing relevant information about the account, such as the account balance. The statement specifies a minimum amount that the cardholder must pay by a certain date to avoid additional charges.

By the end of this guide, you should understand how a Full balance credit program manages credit accounts, including:

• How the program uses configurable entities (transaction types, transaction categories, and program transaction types).
• How the program handles overdue transactions.
• How the program discharges transactions.

You should also understand how to create and configure a Full balance credit program.

How a Full balance credit program manages credit accounts

Every transaction in a credit program is either a debit transaction or a credit transaction.

A debit transaction can be:

• A purchase with network authorization.
• A debit adjustment made by a force operation.
• A purchase through on-us authorization.

A credit transaction can be:

• A cardholder’s payment to their account.
• A network credit voucher authorization.
• A credit adjustment.

Every credit program has a credit card cycle. This is the period of time that is covered by a single customer statement. It’s also called the billing cycle.

The total amount due or debt is the amount that the cardholder owes on their card. The total amount due equals the total debits minus the total credits. This is normally the only amount the cardholder needs to worry about. However, to support regulatory and tax requirements, the Pismo platform tracks balances for individual transactions.

When the cardholder makes a payment (credit transaction), the Pismo platform uses it to reduce the balance of one or more debit transactions.

If a debit transaction becomes overdue, charges are normally applied that increase its balance.

For each credit cycle, an account has a cycle closing date and a due date. On the morning of the cycle closing date, the Pismo platform uses the credits and debits for the cycle to calculate the total amount due, minimum amount due, and any interests, taxes, or fines and posts them to the cycle. It then closes the cycle.

🚧

Any new transactions that take place on the cycle closing date are usually posted in the next cycle, since the previous cycle is closed right at the beginning of the day. However, if a transaction happens on the cycle closing date, but before the cycle is closed, it’s posted in that cycle.

The due date is the last day that the cardholder can pay the minimum amount due before incurring charges for late payments. If the due date is not a business day, the Pismo platform finds the next business day and uses that date to populate a field on the statement called “Real due date”.

How the Pismo platform handles credit voucher authorization

A credit voucher is a document submitted by a merchant to an acquirer (usually a bank) as evidence of a partial or total refund of a charge. The voucher is submitted to the card network for processing, after which, it’s submitted to the Pismo platform as a network credit voucher.

By default, when a network credit voucher is received, the Pismo platform waits for clearing or Base II processing to be completed before updating the account limit or balance. If you wish to decline this recommended behavior, open a ticket with the Pismo Service Desk stating that you wish to decline it and that you would like the account limit or balance impact to occur at the time of authorization. Be aware, however, that you do this at your own discretion, based on your unique objectives, internal policies, and any legislation to which you might be subject.

How the program uses configurable entities

Full balance credit programs use the following configurable entities to determine how to apply charges to overdue transactions and how to discharge transaction balances:

• Transaction types
• Transaction categories
• Program transaction types

Transaction types

A transaction type identifies a transaction as either a credit or a debit. It also determines whether the transaction should be listed on the monthly statement.

Transaction types are defined at the organization level. See Processing codes and transaction types for more information.

Transaction categories

A transaction category is used to group transaction types. It has the following parameters:

• Minimum payout percentage — Used to calculate the minimum amount due.
• Charge order — Used to determine the priority order when discharging transaction balances.
• Rates for interest, fines, and taxes

Transaction categories are defined at the program level.

Program transaction types

A program transaction type serves to unite a transaction category, a transaction type, and a program. It does this by including fields for the transaction type ID and the transaction category ID. Since a transaction category is defined for a program, this links the transaction type to that program.

Note that multiple program transaction types can link to the same transaction type. In this way, different programs can use the same transaction type. However, that transaction type is linked to a different transaction category for each program (via the program transaction type).

Program transaction types are defined at the program level.

How the program handles overdue transactions

The statement due date applies to all the debit transactions posted during that credit cycle. So, although each debit transaction happens at a different point in time, all of them become overdue on the same day (the day after the due date). The Pismo platform can apply different charges for overdue transactions. These include:

• Refinancing interest — Interest charged on the unpaid amount when the cardholder doesn't pay the total amount due by the due date. Different refinancing interest charges can be configured in the transaction category, depending on whether the cardholder pays the minimum amount due before the due date or not. (A higher rate is normally charged if the account is overdue.)
• Taxes — Supports only IOF (Brazilian market).
• Interest on cash withdrawals / bill payments — Charged beginning on the day after the transaction date until the due date.
• Fines — Various fees that can be charged on overdue transactions.

How the program discharges transactions

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 (that is, when it’s been paid in full), it's said to be written off.

The Pismo platform runs the discharge process on these 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 writing 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 to the next cycle.
• Immediately before closing the credit cycle — In this case, the discharge process continues writing 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 written off by the discharge process. These rules ensure that overdue transactions are written off first.

The payment hierarchy divides transactions into these groups:

• Group 1 — Late transactions from an overdue invoice through the current day minus 1.
• Group 2 — Past invoice open transactions. Transactions can fall into this category when a payment is made between the cycle closing date and the due date.
• Group 3 — Transactions in the current credit cycle.

The transactions in group 1 are discharged first. After they are all written off, the Pismo platform starts discharging transactions in group 2. Transactions in group 3 are the last to be discharged.

Within each group, transactions are discharged in the following order:

• Transactions with the lowest charge orders, as defined in their associated program transaction types, are discharged first.
• Transactions with the oldest statement due dates are discharged next. So, unpaid transactions carried over from earlier statements are paid off before transactions from the current statement.
• Transactions with the lowest charge orders, as defined in their associated transaction type categories are paid off next. (Note that charge orders configured in program transaction types override charge orders configured in transaction categories.)
• 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 written off within a group.

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:

Note that 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 transaction category.

Suppose you have a 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 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

Creating and configuring a Full balance credit program

Now that you understand how a Full balance credit program works, you’re ready to create and configure your own.

Creating the program

Use Pismo Control Center to create your Full balance credit program. Pismo provides a program template as a starting point for a new Credit Full Balance program. Alternatively, if you already have an existing full balance credit program, you can copy it. For more information, see Adding programs.

🚧

You can't change the program type of an existing program, so make sure you choose credit and Full balance during the creation process (or copy a program of the correct type).

Configuring the program in Control Center

After creating the program, use Control Center to configure it. For example, the Applicable charges tab enables you to specify rates for various charges. For more information, see Manage program details and parameters.

Adding configurable entities

Transaction types are independent of any specific program, so you can optionally create them before creating your first program. A transaction category, however, must be linked to a program at creation, so you have to create categories after creating their associated programs. Since program transaction types are linked to transaction categories at creation, these entities must be created last.

• Transaction types — Use the Create transaction type endpoint. In the request, you must specify whether the transaction type is a credit or debit. You also must specify whether the associated transactions should appear on the customer’s statement.
• Transaction categories — Use the Create transaction category endpoint. You must set values for the various rates in the request. You also have the option of specifying a charge order.
• Program transaction types — Use the Create program transaction type endpoint, passing the program ID as a query parameter and the IDs of the regular transaction type and the transaction category as body parameters. You also have the option of specifying a charge order as a body parameter. This charge order, if present, takes precedence over a charge order defined in the transaction category. Once a program transaction type is created, you can modify its settings using the Update program transaction type endpoint.