Applying Credit Limits to Balances

About Credit Limits

A credit limit is the maximum amount of a balance element that can accumulate in a balance group. When a credit limit is reached, businesses typically deny customers access to the services associated with the balance group. For example, you might set a credit limit of $100 for a telephony package and deny service when customers who reach that limit try to place a call.

You can also configure charges to allow customers to exceed their credit limits. See "Allowing Customers to Exceed Their Credit Limit".

You set credit limits for balance elements in packages.

About Credit Thresholds and Floors

You can use credit thresholds to notify customers when they are approaching the credit limit of a balance. A credit threshold specifies the balance total that triggers a notification to the customer. You can specify the threshold in the following ways:

As a fixed value, such as $100 or 30 minutes.
As a percentage of the credit limit, such as 90%. For example, if the credit limit is $100 and the threshold is 90%, the threshold amount is reached when the customer has a balance of $90 (that is, when the customer has used 90% of the balance).

The credit floor is the starting point for a credit threshold and is the lowest number that the balance can be (that is, the number that represents no use of the balance).

For currency balances, the credit floor is 0.

For noncurrency balance elements, such as prepaid hours, you must specify a credit floor. You can use a negative number for the floor. For example, suppose you give 100 prepaid hours and set the credit limit to 0. When the credit limit is reached, the customer has no hours remaining and cannot use the service. To notify the customer when only 10 hours remain, set the credit threshold and floor as follows:

Set the credit floor to -100. This number indicates none of the balance has been used.
Set the credit threshold to 90%.

The threshold is reached at 90% of -100 hours (that is, when the customer has 10 prepaid hours left).

The credit threshold can be triggered both when a balance is increasing and when it is decreasing. You can customize BRM to perform different actions in each case. For example, if the credit threshold is crossed when the balance is increasing, service could be turned off. If the threshold is crossed when the balance is decreasing, service could be restored.

Handling Credit Limit Conflicts

There might be occasions when customers purchase packages with credit limits that conflict with the credit limit set on their account or another service. There are two ways to handle credit limit conflicts:

When you create your product offerings, if two services have different credit limits, create new balance groups for the services. This enables credit limits for each service to be set and tracked independently. See "Tracking Balances in Balance Groups".
Specify which credit limit takes precedence when a new credit limit conflicts with an existing credit limit. You do this by setting the credit_limit_conflict entry in the CM configuration file.

To specify credit limit precedence:

Open the CM configuration file (BRM_home/sys/cm/pin.conf).
Add the credit_limit_conflict entry:
```
-fm_bill credit_limit_conflict value
```
where value is one of these values:
- replace to use the new credit limit.
- ignore to ignore the new credit limit and keep the existing credit limit.
- add to add the new credit limit to the existing credit limit and create a new limit.
- minimum to use the credit limit that specifies the smaller amount.
- maximum to use the credit limit that specifies the greater amount.
If this entry is not present, the new credit limit is used by default.
Stop and restart the CM.

Allowing Customers to Exceed Their Credit Limit

When configuring properties for quantity ranges in charges, you can specify what happens to subscriptions when customers exceed their credit limits. You can do the following:

If you do not want to allow customers to exceed their credit limit, you can specify that:

The subscription succeeds and the resources are prorated according to the available balance. For example, if the subscription grants 2GB of data and costs $10, but the customer only has $8 in their account, the $8 would be used and the customer would be granted 1.6GB of data.
In the PDC UI, this is the Enforce Credit Limit option.
The subscription fails. After retrying the subscription the configured maximum number of times, a notification event is sent to an external system for further processing.
In the PDC UI, this is the Rental Failure option.

You configure the maximum number of retries in the max_retry_count subscription business parameter. The default is 0, which sends the failure notification immediately without retrying. See "Using Event Notification" in BRM Developer's Guide for information about notifications and "Configuring the Maximum Number of Subscription Retries" for information about the maximum number of retries.

The current number of retries for the subscription is recorded in the PIN_FLD_RETRY_COUNT field of the /purchased_product object.

If you create charge offers in XML using the ImportExportPricing utility, you can also configure the maximum retries and their interval at the offer level. See "Enforcing or Exceeding Credit Limits" for more information. If nothing is configured for the offer, the business parameter is used.

If you want to allow customers to exceed their credit limit, you can specify that:

The subscription succeeds and all available balance is used. The remaining amount is recorded as a negative account balance to be paid at the next top up for prepaid customers or next bill for postpaid customers.
In the PDC UI, this is the Do not enforce credit limit option. You typically use this option for postpaid customers.
The subscription succeeds and all available balance is used. The remaining amount is recorded as an outstanding amount to be paid at the next top up for prepaid customers or next bill for postpaid customers.
In the PDC UI, this is the Deduct Rental option. You typically use this option for prepaid customers.
The subscription succeeds. If the customer is eligible for a loan, all available balance is used and a loan is granted for the remaining amount. If the customer is not eligible for a loan, the subscription fails.
In the PDC UI, this is the Loan option.

See "About Loans" in BRM Configuring and Collecting Payments for more information about loans.
The subscription succeeds without using the available balance. The entire amount is recorded as an outstanding amount to be paid at the next top up for prepaid customers or next bill for postpaid customers.
In the PDC UI, this is the Outstanding Amount option.
The subscription succeeds without using the available balance. Billing will be skipped for this cycle; during rating all balance impacts are dropped and the unrated quantity is set to 0. The cycle forward date is moved to next cycle. Services are still available.
In the PDC UI, this is the Skip Cycle option.

If you create charges using the ImportExportPricing utility, you have additional options for exceeding credit limits. See "Enforcing or Exceeding Credit Limits" for more information.

Configuring the Maximum Number of Subscription Retries

When a customer's subscription fails due to insufficient credit, the subscription can be retried a configured number of times before sending a failure notification to an external system.

The maximum number of retries is configured in the max_retry_count field in the business parameters for subscriptions. By default, this is set to 0, which sends the notification immediately without retrying.

To change max_retry_count, use the pin_bus_params utility:

Go to BRM_home/sys/data/config.
Run the pin_bus_params utility to create an XML file from the /config/business_params object:
```
pin_bus_params -r BusParamsSubscription bus_params_subscription.xml
```
Search for this line:
```
<MaxRetryCount>0</MaxRetryCount>
```
The default is 0 (no retries).
Specify the new maximum number of retries.
Save the file as bus_params_subscription.xml.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_subscription.xml
```
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter.

See "pin_bus_params" in BRM Developer's Guide and "pin_multidb" in BRM System Administrator's Guide for more information about these utilities.

If you create charge offers in XML using the ImportExportPricing utility, you can also configure the maximum retries and their interval at the offer level. See "Enforcing or Exceeding Credit Limits" for more information. If nothing is configured for the offer, the business parameter is used.