Overdraft protection

The traditional authorization scheme, in which the system checks the amount of available funds at the beginning of a call, has many drawbacks. For one, the system does not respond to balance changes (refunds, payments, or charges) made while the call is in progress. Since every session is authorized based on the total amount of resources available, overdrafts are possible in the case of multiple concurrent sessions and the like. The alternative – restricting the number of concurrent sessions to one – allows you to avoid overdrafts, but is inconvenient for the end user.

This is why PortaBilling offers you the ability to dynamically lock the funds required to pay for a certain amount of service before that service is used. Proper implementation of overdraft protection requires support both on the billing engine side (PortaBilling) and on the part of the network element providing the service, e.g., PortaSIP. (See below for a description of the scenarios applicable to “legacy” switches.)

What is the relationship between authorization and fund locking? Authorization is simply a check for whether currently available funds are sufficient to cover a service (or how much of service can be used with the funds currently available). Using a simple analogy, it is like taking a look in your wallet to see how much money you have left before deciding whether you have enough to purchase a DVD or buy some chocolate bars. The problem is that such a check is done without taking into account your other attempted purchases. For example, if you have $20 available, the system will tell you that you have enough money to buy 1 DVD ($15) or 10 chocolate bars ($2 each), but it cannot tell you whether you can buy a DVD and also buy 2 chocolate bars.

Fund locking not only checks that you have enough money for the DVD, but also immediately puts that money into a different compartment of your wallet. Now when you check to see how many chocolate bars you can buy, you will be working with only the remaining portion of the money. This will spare you an awkward situation at the cash register.

The simplest overdraft protection scenario is “resource locking.” This is done when an application knows the amount of funds required beforehand. So right at the start, the application sends a request to validate the availability of these funds and if this is successful, it locks them. Then, when the purchase has been completed, a “charge” event is sent to PortaBilling. One example of such a service is pay-per-view content distribution. After a customer clicks on a “Get the movie” link, the system authorizes and locks the funds to cover the cost of the movie to ensure that the customer has the right permissions and sufficient funds. The customer is then shown a confirmation dialog box. If he approves the purchase, the money is deducted from his account.

Dynamic re-authorization is a more complex process used when it is not possible to tell how much a customer will spend in a particular session, so that additional funds must be locked “on the go.” When a session (e.g., a voice call) starts or is in progress, the system “reserves” a small portion of available funds to cover the next time interval (e.g., 5 minutes). As the end of this interval approaches, the system attempts to reserve funds to cover the next interval, etc. If no remaining funds are available, the call is disconnected. So if a customer sends an SMS message during a phone call (decreasing the available funds), or makes a credit card payment (increasing the available funds), that immediately affects the call – and either the call is disconnected sooner or the maximum allowed call time increases.

Let’s see how dynamic re-authorization works in a specific example where an account is concurrently using multiple services and making a payment while the session is still in progress.

• Initially, the account has $12 available.
• The user starts a phone call to a destination with a price of $0.30 per minute. PortaSIP requests call authorization for 5 minutes. At this point the user’s balance is still unchanged, but funds covering a 5-minute phone call ($1.50) are locked (1).
• While the call is in progress, at some time before the end of the “approved” period (for our example, we’ll assume this is one minute), PortaSIP will attempt to perform re-authorization.
• PortaSIP sends a re-authorization request to billing. PortaBilling verifies that the account has enough funds for another 5 minutes. The amount locked is now $3.00 (2).
• While still on the phone, the user decides to purchase a pay-per-view movie. An authorization request arrives from the IPTV platform, and the funds needed to pay for the movie ($5.00) are locked in addition to the previous $3.00 (3).
• The user now attempts to purchase another movie ($5.00), but this request is rejected since he only has $4.00 left 4).
• The purchase of the first movie is completed, and the balance decreases to $7.00 (5).
• Since the call is still in progress, and the end of the “authorized” time is approaching, PortaSIP sends another authorization request, and so funds for another 5 minutes are locked (a total of $4.50 is now locked) (6).
• The user keeps talking, and so 5 minutes later yet another authorization is sent. The total amount of locked funds is now $6.00 (7).
• Soon another authorization is sent, but now there are only enough funds for 3 minutes. $6.90 is now locked (8).
• The user realizes that he is running out of money, but wants to continue the phone call, and so he promptly makes an online payment with his credit card. $4.00 is deposited to his account (9).
• Since the last re-authorization provided less time than requested (3 minutes instead of 5), PortaSIP determines that the user is out of money, and normally it would disconnect the call. However, it makes one last re-authorization attempt, one minute before the call is to be disconnected (10).
• Since the user now has available funds, another 5 minutes of call time are authorized. The total amount of locked funds is now $8.40 (11).
• Finally, the user disconnects, and is charged $7.80 for the full call duration of 26 minutes. Thus his balance is now $3.20 (12).

There are two situations that may lead to an excessive locking of funds:

• Attempting to use an “expensive” service – for instance, let’s assume that PortaSIP is configured to lock sufficient funds for a 15-minute conversation at the start of a call. This is fine for calls to the US or Europe (in which case only 20-40 cents would be locked). But if a customer with a fairly low balance calls an expensive destination (e.g., Somalia – $1.00/min), he may find that all of his funds are suddenly locked and he cannot use another service in the meantime.
• Old-style applications that do not support re-authorization – if an authorization request comes from a gateway or switch that does not support dynamic fund locking, then all available funds will be locked while that session is in progress.

To prevent locking too many or all available funds, the administrator can limit the maximum fund allocation for each subsequent fund lock.

For “overdraft protection-aware” applications, each request will lock no more than the amount specified in the Each subsequent fund lock allocates no more than field. Taking our example of a call to Somalia, if we set this parameter to $3.00, the billing engine will respond to PortaSIP’s request to lock funds sufficient for 15 minutes by locking up only $3.00 (3 minutes). Thus PortaSIP will perform a re-authorization every three minutes.

For applications that do not support dynamic re-authorization, the maximum call duration will be limited to the amount defined in the Each subsequent fund lock allocates no more than field. Thus, if we set this parameter to $3 and dynamic re-authorization is disabled for the call to Somalia, it will last only 3 minutes and then be disconnected.

By using volume discount plans, service providers can either adjust users’ pricing depending on the volume of the service used or they can allocate some free services (e.g., minutes, GB, etc.) to their users. In cases where several accounts share the same quota and initiate sessions more or less concurrently, PortaBilling must be aware of quota usage by each account to prevent them from going into overdraft.

Therefore, when authorizing a session, PortaBilling allocates a portion of the available quota and locks that allocated portion for the authorized session. Then it excludes that locked quota portion when it authorizes simultaneous customer sessions.

When locking a quota, PortaBilling considers the following:

• customer balance;
• tariff rates;
• maximum session duration either defined by the administrator or provided by NAS; and
• the fund locking configuration defined within the product.

Consider the following example:

Let’s say John Doe has a $0 balance and a $10 credit limit. His tariff plan allows him and his wife Jane to make calls to Canada for $0.5 per minute. They also share a quota for 50 free minutes to Canada. For them to make simultaneous calls and at the same time, not exceed their credit limit, PortaBilling authorizes their calls for $3. The administrator has defined that all calls may last no longer than 30 minutes.

When John calls 16045556754, PortaBilling considers the available quota against the maximum allowed call duration – 30 minutes. Since 50 > 30, PortaBilling locks 30 minutes from the quota, and leaves 20 minutes available.

Five minutes later, Jane dials 16045557785. PortaBilling considers the remaining quota – 20 minutes, against the maximum allowed call duration – 30 minutes. Since 20 < 30, PortaBilling locks the remaining quota and adds another 6 minutes to it, calculated based on the call cost and the authorization amount ($3 * $0.5/min = 6 min). Thus, Jane is authorized to make a 26-minute call.

After 15 minutes, John hangs up. Since John’s call lasted 15 minutes, PortaBilling unlocks those unused 15 minutes and makes them available for other calls.

PortaBilling locks the counters for any type of volume discount plan (discounts, quotas, and service wallets) for both RADIUS- and Diameter-based sessions. To enable this functionality, your service configuration must meet the following conditions:

• Your product must have Overdraft protection functionality enabled; and
• The value of the discount threshold must have a limit.

In order to fully use overdraft protection capabilities, the node providing the service (gateway, switch, etc.) must send the proper attributes in the RADIUS request to PortaBilling. During the initial authorization request, it will inform PortaBilling of the desired interval for fund locking (and the minimum possible interval for re-authorization), and will then periodically issue re-authorization requests. Real-time overdraft protection is fully supported by PortaSIP.

What happens when a node that is not capable of dynamic re-authorization sends a “standard” RADIUS authorization request? Also, how does fund locking affect the number of concurrent sessions available for a customer?

Answer: the product configuration features an Overdraft protection setting that allows you to define how fund locking is applied:

• When overdraft protection is disabled, that means there are effectively no “locked” funds. Thus, for concurrent sessions, PortaBilling computes the maximum session duration based on the total amount of customer’s available funds for each session separately. So in the case of several concurrent sessions, each can potentially use up the available funds. This method provides transparency for the application using overdraft protection, although, in reality, it does not provide greater security than a simple authorization request does. For obvious reasons, it is not recommended for general use.
  When disabling overdraft protection functionality, make sure that the product is only assigned to credit accounts. Otherwise, it may open the overdraft option for debit accounts.
• When enabled, fund locking is done on all account types. For “overdraft protection-aware” applications, the amount of funds locked is the lesser of either the amount necessary to cover the requested service or the amount defined in the Each subsequent fund lock allocates no more than field. For legacy authorization requests, it represents either all of the available funds or the amount defined in the Each subsequent fund lock allocates no more than field. Note that if all of an account’s available funds are locked for a session, more paid sessions cannot be established.