---
updatedAt: 2026-07-24T12:30:42.000Z
agentTools:
siteIndex: https://developers.pismo.io/llms.txt
projectIndex: https://developers.pismo.io/pismo-docs/llms.txt
---
# Full balance credit program
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, program 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.
# Managing 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](https://developers.pismo.io/pismo-docs/docs/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. For more information, refer to [Handling credit voucher authorization](https://developers.pismo.io/pismo-docs/docs/full-balance-credit-program#handling-credit-voucher-authorization) .
* A credit adjustment
Every credit program has a [credit card cycle](https://developers.pismo.io/pismo-docs/docs/understanding-statements#credit-card-cycles-billing-periods). 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 of all 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 the account 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 statement. 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 nominally the last day that the cardholder can pay the minimum amount due (MAD) before incurring charges for late payments. However, the cardholder might be granted more time to pay the MAD under the following conditions.
* You can use the **Defines the number of additional grace days granted to the program** program parameter to give the cardholder one or more additional days to pay the MAD before charges start to accrue. This value is added to the due date to get the **real due date**, which appears as a field on the statement.
* If the due date (or the real due date, if **Defines the number of additional grace days granted to the program** is set), is not a business day, the Pismo platform finds the next business day and uses that date for the real due date.
To sum up:\
real due date = due date + additional grace days + adjustment for non-business days
The Pismo platform calculates charges for late payments starting from the due date, not the real due date. If the cardholder pays the MAD by the real due date, then those charges are never applied.
## Handling 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](https://developers.pismo.io/pismo-docs/docs/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.
## Using 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
* Program 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. For more information, refer to [Processing codes and transaction types](https://developers.pismo.io/pismo-docs/docs/processing-codes-and-transaction-types) .
### Program transaction categories
Use program transaction categories to set properties such as charge order and accrual rates at the program level for a group of related transaction types. For more information, refer to [Program transaction categories](https://developers.pismo.io/pismo-docs/docs/transaction-category-structure#program-transaction-categories).
### Program transaction types
Use program transaction types to associate program transaction categories with transaction types. For more information, refer to [Program transaction types](https://developers.pismo.io/pismo-docs/docs/program-transaction-types).
## Handling overdue transactions
A transaction is overdue if it meets the following criteria.
* It has an unpaid balance.
* It appears on a statement whose due date has passed.
The real due date applies to all the debit transactions posted during that credit cycle. So, although each debit transaction posted on that statement happens at a different point in time, all of them become overdue on the same day (the day when the account becomes overdue).
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 real due date. Different refinancing interest charges can be configured in the program transaction category, depending on whether the cardholder pays the minimum amount due before the real 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 paid off.
* **Fines**—Various fees that can be charged on overdue transactions.
* **Overdue interest**—Interest charged on an unpaid balance after the real due date when the MAD has not been paid.
As explained in [Credit liquidation](https://developers.pismo.io/pismo-docs/docs/credit-liquidation), an account's collection status changes to `OVERDUE` if the MAD is not paid by the due date + **Number of days to block the account for unpaid statement** . This causes the account to be blocked.
On the other hand, a transaction with an unpaid balance becomes overdue after the real due date of the statement, if the MAD has not been paid. Accruals are calculated starting from the due date (which could be before the real due date). This usually happens before the account's status changes to `OVERDUE`.
It's important not to confuse these two things. Although overdue transactions can lead to an account being blocked, they don't have to, and an account normally starts accruing overdue interest before it's actually blocked.
## Discharging transactions
The **discharge process** defines how a cardholder's 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. For more information about the discharge process, refer to the [Discharging transactions](https://developers.pismo.io/pismo-docs/docs/discharging-transactions) guide.
## Closing an account
To close an account, set its account status (`status`) to a final status, such as `CANCELLED`. Once an account is closed, you can't change its status using the [Update status](https://developers.pismo.io/pismo-docs/reference/patch-accounts-v2-accounts-accountid-status) endpoint. If you need to reopen a closed account, you must use the [Rollback status](https://developers.pismo.io/pismo-docs/reference/patch-v2-accounts-accountid-status-rollback) endpoint.
By default, closing an account does not automatically stop the Pismo platform from opening and closing credit cycles for that account. This can have a performance impact on the credit cycle, so it's a good idea to configure the platform to permanently stop the credit cycles when an account is closed. For instructions on how to do this, refer to the next section.
## Definitive cancellation: Permanently stopping credit cycles
In some business scenarios (for example, charge‑off, legal cancellation, or irreversible account termination), issuers must ensure that no new credit cycles are opened or closed for an account. There are two options for doing this.
> 🚧 Important (applies to both options)
>
> Once an account is definitively canceled, the Pismo platform permanently stops closing credit cycles for that account. This behavior is irreversible, even if the account status is later changed. This is not specific to any of the following options, but to the fact that the account reached a definitive‑cancellation state as evaluated by the platform.
### Option 1: Disable credit cycle features for the account
This is the preferred and most reliable approach. Use the [Configure features by account status](https://developers.pismo.io/pismo-docs/reference/postfeaturesbyaccountstatus) endpoint to configure the credit cycle to disable specific lifecycle features when an account reaches a given status (for example, `CANCELLED`). To fully stop credit cycles, set the following fields to `false` in the `features` object.
* `close-statements`
* `create-accruals`
* `late-payment-fee`
* `overlimit`
With these features disabled, the Pismo platform does not execute cycle logic for accounts in that status **regardless of future status changes**.
### Option 2: Create and apply a `DEFINITIVE_CANCELLATION` account status
This is the legacy approach. Option 1 is recommended. Use the [Create status](https://developers.pismo.io/pismo-docs/reference/v4-post-account-status) endpoint to define a custom account status called `DEFINITIVE_CANCELLATION` and apply it to the account. When the Pismo platform detects this status, it permanently stops cycle closing and opening.