Volume discount plans

The volume discount plans tool is great for making automatic price adjustments and allotments. It allows you to adjust prices depending on the volume of services consumed by customers, allocate a certain volume of free services and transfer a balance to a sub-wallet that has been designed for a particular type of service. These are the three main discount schemes:

• Discounts – using discounts, you can adjust prices depending on the volume of service consumed by customers. This encourages them to use the service more in order to receive the discount (e.g., spend $20 for calls to the UK and get a 30% discount for the next calls during the month). You can also use discounts to make special offers (e.g., new customers receive 50% off for 10 GB of Internet traffic).
• Quotas – with quotas you are able to allocate a defined volume of services for your customers free of charge. A quota is usually combined with a recurring fee (a subscription). For example, provide 100 minutes for calls to Canada and 3 GB of Internet traffic for a $30 monthly fee.
• Service wallets – this tool makes it possible to divide the customer’s balance into virtual sub-wallets. Each sub-wallet is designated for a specific service and destination group. Therefore, money transferred to a sub-wallet can only be used for a specific service (e.g., only for calls to the US or only for sending SMS, etc.). For example, a customer wants to have unbroken access to the Internet even if all his available funds have been consumed by making calls. So the customer tops up his Internet service sub-wallet by $10 using a credit card. The customer receives 5 GB of Internet traffic that can be used even when his available funds reach zero. Service wallets can be topped up via the self-care or administrator web interface.

Use these discount schemes separately or combine them with each other to get the best solution for your business model. For instance, your service may include 300 free monthly minutes to US & Canada, 100 free monthly minutes to Western Europe, and a special offer of 15% off calls to India after the customer has called for more than 200 minutes. Each of the conditions above is represented by an individual discount scheme. Taken all together, they will be grouped as volume discount plan “EasyCall,” which can then be applied to a specific account.

Use this discount scheme to provide a discount for a defined usage period – daily, weekly, semimonthly, or monthly. When the usage period ends, the discount counters reset. For example, provide a monthly deal of the first 100 minutes for calls to the UK at a standard rate, the following 200 minutes at a 20% discount, and all following calls to this destination at a 30% discount. When the next usage period begins, the customer’s calls to the UK are charged the standard rate.

You can also provide one-time discount. This discount type is a great tool for providing a permanent discount with no time limitation. For example, apply this discount type to provide a rate that is 10% cheaper for a wholesale partner.

A detailed description of how the billing engine calculates a discount is considered in the following example:

• You have the discount rule “first 200 minutes – regular rate $0.20/min, 15% discount after 200 minutes” for calls to Israel.
• During one month the customer spends 230 minutes on the phone.

In this case, I will charge the customer 200*0.20 + (30*0.20 – 15%) = 40 + 5.1 = 45.1. Sometimes people get confused, and will assume that the charges in this case should be 230*0.20 – 15% = 39.1, which is incorrect. (In order to provide a discount to the total amount of services consumed use the Bundle Promotions feature).

This is the most common way to provide a set of services for a recurring fixed fee. To do this, create a quota for your service, then create a subscription plan and assign them both to the same product. For example, you can provide a triple-play package that includes quotas such as 1000 minutes for domestic calls, 1 GB of Internet traffic, and 150 domestic SMS – for a monthly subscription fee of $40. Once the quota is consumed, the service is unavailable until the following month.

Sometimes customers want to reserve an amount of money for a specific service so they can freely use their available funds for other services. If a customer runs out of money at some point, the money in reserve remains available and the customer can still spend it only for the needed service. Within a single volume discount plan, the administrator can configure as many service wallets as needed. The volume discount plan can be assigned to a product, a customer or one of their accounts. When assigned, the service wallet with zero initial balance is empty, so in order to use it, the customer or administrator needs to top it up. Alternatively, there is the option of configuring a service wallet with an initial value.

Use this service wallet scheme to grant a certain volume of service to your customers for one time. For example, grant your IPTV customers 1 GB of Internet traffic free of charge as a promotional offer. Once the traffic is consumed, the customer may decide whether to top up their service wallet for more Internet service or not.

This is a fast and easy-to-use tool to reserve customers’ money for a specific service. The administrator or user can top up the service wallet at any time via their web interfaces. A top-up is an efficient way to increase your payment flow since you, as the service provider, can sell a larger volume of service at a lower price. For example, you can offer 10-minute calls to Germany for $3; 50-minute calls for $10, and 100-minute calls for $15. The user selects the most suitable offer among the three options and either tops up his service wallet via the customer/account self-care web interface or requests this service from the administrator.

Consider the following example:

John Doe is a prepaid customer of EasyCall Inc. To be on the safe side, John Doe wants approximately 10 SMS and about 100 minutes for domestic calls in case he runs out of money using other services. He accesses the customer self-care interface and sees these available options:

• 20 SMS for $3 and 50 SMS for $6;
• 50 minutes for $5, 100 minutes for $9, and 200 minutes for $15.

John Doe buys 20 SMS for $3 and 100 minutes for $9, his credit card is charged for $12. Now he can use other available services (e.g., he surfs the Internet and makes international calls) feeling confident that this will not impact his ability to make domestic calls and send SMS messages.

Customers can top up their service wallets using payment processors that require user redirection to their website for payment processing, such as PayPal, Skrill, and Payarena.

When a customer initiates a top-up from their self-care interface, they are redirected to the payment processor portal to provide their credit card/account information and confirm payment. Upon payment processing, the customer is redirected back to the self-care interface where they can view the updated service wallet balance.

With PortaBilling you can fine-tune service provisioning for possible situations like when a customer’s service wallet for accessing the Internet is empty. For this situation, configure the system to:

• block service until the customer tops up their service wallet; or
• continue to provide service but draw the funds from other applicable service wallets or from the customer’s main balance.

Thereby you clearly define the system’s behavior and also facilitate service provisioning.

One popular business model is to offer service provisioning for a certain period of time. This way, service providers encourage customers to make frequent top-ups so they can keep using the service.

With PortaBilling, you can introduce this business strategy by using service wallets that have a lifetime. Each top-up extends a service wallet’s lifetime. Once a user makes a top-up, they can use the service for the period defined (i.e. the lifetime), after which it expires. Thus, the more a user tops up, the longer they can use the service. Note that service wallets that have an initial balance defined do not have an initial expiration date (i.e. the initial balance can be used unrestrictedly. It obtains its lifetime from its top-up).

If a user tops up a service wallet before it expires and there is an unused quota/balance, it is added to the top-up quota/balance. The service wallet lifetime, however, is not added: if the top-up lifetime is for less time than the current one, the service wallet lifetime is not extended.

Consider the following example:

You are the Internet service provider and offer the following top-up options with your Start Internet service wallet:

• 5 Gb for $5 and a lifetime of 2 days;
• 10 Gb for $8 and a lifetime of 5 days;
• 25 Gb for $20 and a lifetime of 10 days.

John Doe has signed up for the Start Internet product and makes a $5 top-up. He sees that he has a 5 Gb Internet quota that is available for 2 days. During the day, he uses 4 Gb, so he needs to make another top-up to continue surfing the Internet. He makes an $8 top up and now he has an Internet quota of 11Gb (by adding the unused 1 Gb from the previous top-up plus the new top-up for 10 Gb) which is available for 5 days. If John Doe does not make another top-up in 5 days, he will receive a notification about his quota expiration.

Note that if you grant a user some Internet quota (e.g., either as a promotion or compensation for quality issues), it will not affect the service wallet lifetime. Thus, if you provide John Doe with 1 Gb extra, his increased 12 Gb quota will still expire in 5 days.

By offering service wallets with different lifetimes, service providers can introduce marketing campaigns that facilitate service provisioning and boost sales.

The table below matches the most common business cases and discount schemes suitable for them. Use this table to select the proper option for your own business model.

Allocating separate balances for service usage in service wallets enables you to manage customer funds effectively. At the same time, your revenue increases, since customers top-up several service wallets at a time to access the service.

Another step in service usage management is to allocate a common balance that can be used for a subset of services. For example, allocate a $50 service wallet for domestic calls, SMSs, and Internet access and reserve the main balance to be used for international calling. Thereby you introduce quad-play services while monetizing their consumption efficiently.

To narrow down the services available within a common balance, consolidate them into service pools.

Every service within a pool can be measured differently (e.g., voice calls are measured in minutes, Internet access – in megabytes, etc.). Therefore, service pools are measured in unified virtual units.

Virtual units are used to express the cost for using a particular service that is included in the pool (e.g., one minute of calls costs 5 units while an SMS message costs 1 unit). If your pricing changes, you can conveniently re-configure it within the service pool.

Let’s consider multi-service wallets and quotas, separately.

Using multi-service wallets, you can allocate a common balance for your prepaid customers and allow them to use it for different services.

Similar to regular service wallets, in the multi-service wallets, you can identify the service usage as being either monetary or in units. Encourage customers to use these wallets by introducing flexible top-up schemes (e.g., pay $10 and use domestic services worth $12 or pay $20 and use domestic services worth $25). Then when a customer tops up their multi-service wallet, they can use it for any of the services included in the wallet while their main balance remains intact.

To illustrate how multi-service wallets function, consider the following:

You want to distinguish voice calls and domestic SMS delivery from international calls. To do this, create a “Home Plan” service wallet that includes Voice calls and Messaging services.

Prepaid customer John Doe lives in Canada and has $5 worth of available funds. He signs up for the “Domestic Services” product and tops up his service wallet with $10. Each time John makes a call or sends SMSs to Canadian numbers, his $10 decreases.

When John calls his mother in Australia, his $5 worth of available funds decreases.

In some cases, you may not wish to reveal your pricing strategy to customers and/or competitors (e.g., prices are temporarily reduced to promote your triple-play service bundles and attract customers). Multi-service quotas work well for those cases. You offer customers quota consumption in virtual units and at the same time, flexibly define the pricing for each included service and re-configure it when needed.

Consider the following example:

Your “Paradise-100” quota provides 100 monthly units and includes services that are rated as follows:

• Voice calls to USA & Canada destinations – 3 units/minute;
• Voice calls to Europe – 10 units/minute;
• SMSs worldwide – 1 unit/message.

Customer Jane Doe signs up for this quota and starts using it. She calls her mother in New York for 10 minutes – so her quota decreases by 30 units, leaving 70 units available. After she makes a 5-minute call to a friend in the UK and sends 2 SMSs, she still has 18 units available for the month.

To fine-tune the service configuration further for your customers, combine the multi-service quota with regular quotas or service wallets.

For example, you provide domestic calls and SMSs within a multi-service quota while Internet access is provided from a separate service wallet. Thus, whenever a user makes a domestic call or sends an SMS, the quota counters adjust; and when they access the Internet, their service wallet balance decreases.

With this solution, service providers gain additional flexibility with their pricing and service management and can be more competitive in the telecommunications market.

Customers, in turn, can form their own service usage patterns regarding the on-demand consumption of units. In addition, topping up a single service wallet saves time and increases customer loyalty to the service provider.

IoT/M2M service providers can offer their customers group quotas to be shared between multiple SIM cards with the same plan. For example, when a customer activates 10 SIM cards with the “Data 30 GB” plan, their quotas will be combined into a group quota of 300 GB (10 SIMs x 30 GB). If this customer activates 4 more SIM cards with a different plan, e.g., “Data 100 GB”, these will share a separate group quota of 400 GB (4 SIMs x 100 GB).

These group quotas can be calculated and applied to a customer only via an external application using the PortaBilling API.

The group quotas feature is implemented using Add-on Mart Workflows. So, when SIM cards are activated/deactivated under the same plan (e.g., by a customer on the IoT self-care portal, PortaBilling administrator, or external application via the PortaBilling API), the external workflow calculates the combined quota and updates it on the customer level. Service providers that have portals built in-house can also use Add-on Mart Workflows or develop their own script to update group quotas. The external script must be able to:

• listen to PortaBilling events (e.g., a customer activates a new SIM card);

• calculate the combined quota for the customer according to a specific logic (e.g., the quota is prorated if a SIM card is activated in the middle of the billing period); and

• update the combined quota for the customer in PortaBilling.

The group quotas allow customers that use multiple SIM cards to optimize service usage between SIM cards with the same plan. Let’s say, the customer “ABC Security” provides motion detection cameras with SIM cards to their end users, and charges a fixed monthly fee for the security system service. The cameras may consume the Internet traffic unevenly since they send an alert and pictures to a user only when a motion detector is triggered. One camera may use over 30 GB and another one may use only 10 GB. With the group quota, if one camera reaches 30 GB, it just continues consuming the remaining group quota (for 10 SIM cards it’s up to 300 GB). So, “ABC Security” is not charged by their service provider for excess usage (per MB) so long as data in the group quota is available.

• Customers that use multiple SIM cards can avoid high excess usage charges by using group quotas instead of individual ones.

• IoT/M2M service providers can increase sales by offering group quotas to their prospects.

Let’s consider an example.

An IoT service provider “Panda IoT” uses a portal (for example, the IoT portal that is available in the Add-on Mart) where their customers can activate/deactivate SIM cards and choose a plan for them: “Data 5 GB” or “Data 100 GB”. For the SIM cards activated with the same plan, the monthly group quota is provided.

“ABC Security”, a customer of “Panda IoT”, purchases SIM cards to set up home security systems for their clients. Adam Smith, a manager of “ABC Security”, opens the portal to activate 20 SIM cards with the “Data 5 GB” plan. The SIM cards are activated on September 21, so “ABC Security” is charged a prorated fee for 10 days of usage in the current month. Adam can see that the group quota for these SIM cards is 33.33 GB (20 SIMs x 5 GB x 10/30 days).

Let’s say, Adam deactivates 2 SIM cards on September 25 due to the client’s security system re-configuration. Since “ABC Security” has already paid for 33.33 GB, this group quota remains unchanged till the end of September (for 18 SIM cards). On October 1, the group quota is renewed and becomes 90 GB (18 SIMs x 5 GB x 31/31 days). “ABC Security” is charged for 18 SIM cards monthly usage.

Adam can trace the group quota usage on the usage history page.

• To implement group quotas, service providers need to sign up for Add-on Mart Workflows or use another external application. The external workflow or application script is required to dynamically update group quotas via the PortaBilling API.
• No matter whether accounts (SIM cards) are added/changed in PortaBilling via the PortaBilling web interface, the IoT self-care portal, or a custom service provider’s portal, these changes will then trigger the group quota update.
• A SIM card that uses plans for different service types simultaneously, e.g., “Data 30 MB”, “Voice calls 10 min”, and “20 SMS”, can share multiple group quotas simultaneously – separately for each service type.
• Unused traffic of the group plans (such as minutes, Internet traffic, messages) expires at the end of each usage period.

The scenario mentioned above can be implemented using Add-on Mart Workflows or another external application that will update group quotas via the PortaBilling API based on events received from PortaBilling. In PortaBilling, the administrator needs to perform the following steps:

1. On the Configuration server:
   1. Open BillingEngine > Custom group > LoadModules option > add the addonpattern=Porta::Extra::RatePatternRuleAddOn value.
   2. For the group quotas configuration, you will need to create a destination group set (step 2.b) with the same name as specified on the Configuration server. Choose a name for the destination group set and specify it: open BillingEngine > Custom group > IniOptions option > add the value [RatePatternRuleAddOn]MappingSetName=Specify the name.
   3. Open WebCluster > Global environment > DiscountPlans group > set the CustomProratedQuotas option to Yes.
2. On the PortaBilling web interface:
   1. Create custom destinations NETACCESS*5G and NETACCESS*100G.
   2. Create a regular destination group set with the name that you have specified in step 1.b.
      If you haven’t specified a custom name for the destination group set as described in step 1.b, use the default name “Add On Mapping” for the destination group set.
   3. Within the destination group set “Add On Mapping”, create destination groups named “Data 5 GB” (with the destination NETACCESS*5G) and “Data 100 GB” (with the destination NETACCESS*100G).
   4. Create a volume discount plan with the destination group set “Add On Mapping”. This volume discount plan will include all possible quotas (plans):
      • • Create two quotas: with the destination group “Data 5 GB” and “Data 100 GB”. Specify the corresponding thresholds for these quotas – 5 GB and 100 GB.
        • For each quota, open Advanced configuration > Prorate thresholds for first usage period > select the Custom prorating for shared pools option.
3. Create add-on products (plans) named “Data 5 GB” and “Data 100 GB”, and add these add-ons products to the customer’s agreement. This will allow the end users to select these add-ons products (plans) in the IoT portal.
   The add-on products’ names must match the names of the destination groups specified in step 2.c.
4. To charge customers a monthly fee, create corresponding subscriptions and assign them to these add-ons.
5. Enable group quotas for a customer by assigning the volume discount plan created in step 2.d to them.

When an account (SIM card) with a specific add-on product (plan) is created, PortaBilling matches the name of the account’s add-on with the name of a destination group used to define a quota in the customer’s volume discount plan. If there’s a match, the account uses the corresponding group quota from the customer’s volume discount plan.

When IoT/M2M service provider wants to introduce a new plan, e.g., “Panda IoT” decides to offer “Data 50 GB” plan in addition to “Data 5 GB” and “Data 100 GB” plans, the administrator needs to perform the following steps in PortaBilling:

1. Create a custom destination NETACCESS*50G.
2. Open the destination group set “Add On Mapping”, and create a destination group named “Data 50 GB” (with the destination NETACCESS*50G)
3. Open a volume discount plan with the destination group set “Add On Mapping”. This volume discount plan already includes two quotas (plans) with the destination groups “Data 5 GB” and “Data 100 GB”.
4. Create new quota with the destination group “Data 50 GB” and specify the parameters:
   • Select Quota type, Internet service, and the units to measure the service (GB).
   • Select the destination group “Data 50 GB”.
   • Specify the corresponding threshold for the quota – 50 GB.

     

5. Create add-on product (plan) named “Data 50 GB” and add this add-on to the customer’s agreement. This will allow the end users to select this add-on product (plan) in the IoT portal.
   The add-on product name must match the destination group name specified in step 2.
6. To charge a monthly fee for “Data 50 GB” plan, create a subscription and assign it to the corresponding add-on product.

A discount rule is a set of parameters such as the service, thresholds, usage periods, etc. that defines how a discount scheme impacts billing for services. There are three mandatory parameters for each discount rule:

• Service – this parameter defines which service a discount, a quota, or a service wallet is applied to. Select the desired service from the list that represents all available services in your billing environment. Note that within the same volume discount plan you can combine multiple discount rules for different services.
• Destination group – this parameter defines a destination group (a list of prefixes) that will be used in a volume discount definition. For example, if you wish to provide special rates for calls to Eastern Europe you can create a destination group that will contain prefixes for Russia, Ukraine, Belarus, etc. If a customer makes a phone call to 3806325551234 and a matching rate is defined in his tariff for the prefix 380632 (Ukraine, Mobile), the billing engine will search whether any discount rules in the volume discount plan are assigned to a destination group containing the prefix 380632.
  Within the same volume discount plan you can only select the destination groups that belong to the same destination group set.
• Threshold type – discounts, quotas, and service wallets can be configured based on the consumed volume of service (e.g., minutes, Mb, SMS) or on the service cost (note that this cost is calculated using a regular rate). For example, you can use thresholds based on call time (e.g., 10% discount after 200 minutes) or on the call cost (10% discount after more than $10 worth of calls).

When we offer bundles/discounts to our customers, we assign them a volume discount plan. Each volume discount plan consists of one or more volume discount groups, where each group:

• Defines the type of discount (periodically renewed quota of free service, pre-paid service wallet, or progressive discount based on already consumed service volume).
• Specifies which service (e.g., Voice Calls) and which specific destination group such as “Europe” or “Latin America” it applies to. The content (list of specific phone prefixes such as 420 for Czechia) of a destination group is defined in a destination group set; and the volume discount plan is linked to it.
• Provides the actual discount information such as the number of free minutes per month, etc.

When a user (with an assigned volume discount plan) makes a voice call, sends an SMS, or starts an Internet session – the important question is which specific volume discount group will be used (or whether it will be used at all).

There are two main methods that PortaBilling can apply to determine which volume discount group is applicable:

• Comparing the destination (earlier selected for “per usage” rating in the tariff) with destinations in the destination group for the quota/service wallet/discount; or
• Using the so-called “rate pattern” (the full original phone number used by the customer, combined with any applicable special rate codes such as VOICEONNET for calls between VoIP users).

1. The administrator selects a destination group for each volume discount group.
2. PortaBilling can search for the matching destination in the volume discount groups using either the rate earlier selected in the tariff or the rate pattern.
3. If the matching destination is found, the corresponding volume discount group applies.

Sounds complicated, right? Let’s examine specific scenarios.

To define the method that PortaBilling will use to determine which volume discount group is applicable, you need to select a destination lookup type for a volume discount plan. The default lookup type is Matches the rate exactly.

With the Matches the rate exactly lookup type, a quota/service wallet/discount applies only if the destination group associated with the quota/service wallet/discount contains exactly the same destination as the one picked in the tariff for rating.

Let’s say an account has a product with:

• a tariff of $0.05/min to mobile numbers and $0.04/min to landline numbers in Czechia (formerly Czech Republic)
• destination groups
  • “Czechia – landlines” that includes prefixes 420, 4202, 4203, etc.
  • “Czechia – mobiles” that includes prefixes 420602, 420603, etc.
• a 100-minute quota for calls to “Czechia – mobiles” destination group

The account user makes a phone call to 420602555123. First, the rate with the destination for this call is sought in the tariff (if it isn’t found, the call will simply not go through). The rate lookup finds $0.05/min for calls to 420602 (Czechia, Mobile) in the tariff. Then, to check whether the quota should apply, the destination lookup is going to search for exactly the same destination 420602 in the destination group “Czechia – mobiles” associated with the quota. Since the exact same destination 420602 is included in the destination group, the quota applies. The user is not charged for this call (the used minutes are subtracted from the available quota).

Let’s say the user makes a phone call to 420312555789. The rate lookup finds $0.04/min for calls to 4203 (Czechia, Prague) in the tariff. The destination lookup doesn’t find the exact same destination in the destination group associated with the quota. So, the quota is not applied and the user is charged $0.04/min (pay-as-you-go rate) for this call.

If a volume discount plan has several applicable quotas (e.g., it includes two volume discount groups, “Czechia” and “Czechia – mobiles”, the destination 420602 was placed in both, and the customer calls 420602555123), the charging engine uses one of the volume discount groups randomly and ignores the others. This may produce unexpected results, e.g., PortaBilling may choose the quota that is already used up and ignore the available quota. It is best to avoid such ambiguity – for example, if within our product we plan to offer 500 minutes of calls to landlines in Czechia and 100 minutes to mobiles, the correct way is to set up volume discount groups for “Czechia landlines” and “Czechia – mobiles” destination groups with a non-overlapping set of destinations in each.

For special destinations, the destination lookup works the same way – PortaBilling looks for the exact match to apply a quota/service wallet/discount. For example, a user makes an on-net phone call to 420602555888 (which is also a PortaSwitch account). The billing engine recognizes this as a special case, so it does a rate lookup for a special VOICEONNET destination in the tariff. If a rate for such a destination exists in the tariff (usually it does, since this is one of the main advantages of hosted PBX service) – then the quota applies only if the administrator added the exact same destination (VOICEONNET) to the corresponding destination group “VoIP Calls between subscribers”.

A quota/service wallet/discount can apply to incoming and outgoing calls regardless of usage charges in product configuration (no matter whether a single tariff or distinct tariffs are configured for these calls).

So, when you configure a quota, e.g., 100 minutes for calls to mobile numbers in Czechia, you need to be sure that it applies to outgoing calls only and that the minutes of incoming calls are not subtracted from the quota.

For example, let’s say, an account has a product with:

• a single tariff for outgoing and incoming calls (the rate for the INCOMING destination is $0.00/min)
• destination group “Czechia – mobiles” that includes prefixes 420602, 420603, etc. and doesn’t include the INCOMING destination
• a 100-minute quota for calls to “Czechia – mobiles” destination group

When a user receives an incoming call to their phone number 420602555777 (the ID of an account receiving a call), the rate lookup finds $0.00/min for calls to the INCOMING destination in the tariff. However, the minutes are not subtracted from the quota since the destination lookup doesn’t find the exact same destination INCOMING in the destination group “Czechia – mobiles”.

The destination in the destination group associated with the quota/service wallet/discount can be either equal to or more generic than the destination in the tariff.

Let’s say, the account has a product with:

• a tariff of $0.05/min to mobile numbers and $0.04/min to landline numbers in Czechia (formerly Czech Republic)
• destination group “Czechia” that includes prefix 420
• a 60-minute quota for calls to “Czechia” destination group

When the account user makes a call to 420602555123, the rate lookup finds $0.05/min for calls to 420602 (Czechia, Mobile) in the tariff. Then, to check whether the quota should apply, the destination lookup searches for the destination that covers 420602 (either equal or shorter) in the destination group associated with the quota. Such matching destinations can be 420602, 4206, or 420 (if either of these destinations is found, the quota applies). Since the destination lookup finds 420 in the destination group “Czechia”, the quota applies, and the user is not charged for this call (the used minutes are subtracted from the available quota).

Let’s say the user makes a phone call to 420312555789. The rate lookup finds $0.04/min for calls to 4203 (Czechia, Prague) in the tariff. To check whether the quota should apply, the destination lookup searches for the destination that covers 4203. The destination lookup finds the destination 420 in the destination group associated with the quota, so the quota applies, and the user is not charged for this call too (the minutes used are subtracted from the available quota).

If PortaBilling finds a matching destination (that is equal to or shorter than the destination in the tariff) in more than one volume discount group, the longest match is used.

Say, PortaBilling finds destination 420 in the destination group associated with quota A and destination 420602 in the destination group associated with quota B. In this case, the longest match (420602) is used, so quota B applies.

And if PortaBilling finds the longest matching destination (420602) in both quotas – A and B, then a quota applies randomly (either A or B).

Let’s consider an example.

A service provider offers free calls to Spain: 60 minutes for calls to mobile numbers and 30 minutes for calls to landline numbers.

The administrator creates a volume discount plan with two quotas and corresponding destination groups:

When a user makes a call to a mobile number, e.g., 34602555111, the rate lookup finds the applicable destination in the tariff – 34602. PortaBilling searches all the destination groups in the volume discount plan for a destination that covers 34602 (either equal or shorter). PortaBilling finds matching destinations in both destination groups: 346 in “Spain Mobile” and 34 in “Spain”. PortaBilling uses the longest match (346), and the “60-min Spain mobile” quota applies.

And when a user calls 34938555222 (a landline number), the rate lookup finds the applicable destination in the tariff – 34938. PortaBilling finds the matching destination 34 (that covers 34938) in the “Spain” destination group, so the “30-min Spain landline” quota applies.

When this destination lookup type is selected for a volume discount plan, PortaBilling doesn’t consider the destination found in the pay-as-you-go tariff at all. PortaBilling performs the destination lookup based on the rate pattern.

Rate pattern is formed automatically by the system to find the rate in the tariff (rate lookup). It’s formed based on the full original destination number (CLD) combined with the special keywords that PortaBilling automatically adds in some specific call scenarios (VOICEONNET, FAV, INCOMING). So, rate pattern is a combination of the keyword (if it’s used) and the CLD – separated by the | “pipe” character.

For example, these are rate patterns and corresponding rates found in the tariff for different calls:

To check whether a quota/service wallet/discount should apply, PortaBilling uses both parts (keyword and CLD) of a rate pattern, e.g., “VOICEONNET|420602555888”:

1. By design, PortaBilling first uses the keyword, e.g., VOICEONNET. PortaBilling searches for a destination that covers (either equal or shorter) the keyword in the volume discount groups.
2. If no match is found by the keyword, PortaBilling then makes another search using the CLD. PortaBilling searches for a destination that covers (either equal or shorter) the CLD in the volume discount groups.

This lookup type is useful, e.g., when you want to apply a quota/service wallet/discount based on a special destination (keyword) and the pay-as-you-go tariff based on a CLD.

Panda Telecom wants to offer their customers 100 minutes of calls to phone numbers, added as favorites to the “phone book”, for a monthly subscription. Customers can add numbers from all around the world, e.g., Czechia, China, the US, etc. After the 100-min quota is used up, the customers should be charged for calls to these numbers according to their pay-as-you-go tariff (as well as for the calls to other phone numbers, not marked as favorite).

For charging calls to favorite numbers, PortaBilling uses the special destination FAV.

The administrator doesn’t add FAV to the pay-as-you-go tariff, since when the quota is used up, customers should be charged for all calls based on the dialed number (CLD) – and the price will depend on the country where that number is.

For PortaBilling to apply the 100-minute quota to calls to favorite numbers (based on the FAV destination), the administrator adds FAV to the destination group associated with the quota.

With the other lookup types (described above), the scenario when Panda Telecom wants to apply a quota based on the FAV special destination, and the pay-as-you-go tariff based on a CLD is not configurable, because the destination FAV in the destination group associated with the quota would never match the destination in the pay-as-you-go tariff, e.g., 420602.

So, the administrator chooses the Matches the rate pattern lookup type for the volume discount plan.

John Doe, a customer of Panda Telecom, adds 420602555123 to the list of favorite numbers (see the scenario described above). When John makes a call to this number, the rate pattern for rate lookup is “FAV|420602555123” (where FAV is the keyword and 420602555123 is the CLD).

Since there’s no FAV destination in John’s pay-as-you-go tariff, rate lookup finds the 420602 as the matching rate for pay-as-you-go for this call. The next step is to find out whether any quotas or discounts apply.

To check whether to apply the 100-minute quota for calls to favorite numbers, PortaBilling first searches for the special destination FAV in the destination group associated with the quota (since it’s the first part of the rate pattern “FAV|420602555123)”.

As the administrator added FAV to the destination group used for the quota, PortaBilling matches it with FAV in the rate pattern, and the quota applies (since the first part of the rate pattern is found, the second part, 420602555123, is not used for the destination lookup).

And when 100 minutes are used up, the call is charged as usual according to the 420602 rate in the pay-as-you-go tariff.

Let’s say, from the start of the next month, Panda Telecom stops offering the 100-minute quota for calls to favorite numbers. John Doe decides to subscribe to a new bundle with free minutes to Czechia instead. The new volume discount plan is assigned to John’s account via the new add-on product.

420602555123 is still in John Doe’s “phone book” as his favorite number. Next month, John makes a call to 420602555123 (the rate pattern is “FAV|420602555123”).

PortaBilling performs a destination lookup to find a quota to apply and doesn’t find FAV in any destination group in the new volume discount plan. So, PortaBilling makes another search using the dialed number 420602555123.

Note that if John Doe calls a number that is not marked as favorite, e.g., 420602555456, the rate pattern for this call doesn’t contain a keyword: “420602555456”. In this case, PortaBilling makes a search using the dialed number 420602555456 right away.

When destination lookup finds a destination group that includes matching destinations covering the CLD number, such as 420 or 420602, then the corresponding quota applies to the call.

If PortaBilling finds an equal or shorter destination in more than one volume discount group, the longest match is used. It works similarly to If matching destinations are found in several destination groups (for Matches or covers the rate lookup type), with the only difference being that here the destination lookup is based on the keyword/CLD from the rate pattern instead of the destination from the tariff.

With Matches the rate pattern lookup type, the volume discount groups will also apply to the incoming calls if the CLD destination is found in the destination group associated with one of the volume discount groups. This is because this lookup type uses both parts of the rate pattern to search for a matching destination. For example, a customer receives an incoming call to 420602555777 (the ID of an account receiving a call). The rate pattern for this call contains the keyword INCOMING and the CLD: “INCOMING|420602555777”. Let’s say PortaBilling doesn’t find any destination groups that include the special destination INCOMING but finds a destination group (associated with a quota) that includes the destination 420, then the quota applies (e.g., minutes are subtracted from the quota).

If you charge for the incoming calls according to CLD and want to apply a quota/service wallet/discount to both incoming and outgoing calls the Matches the rate pattern lookup type is the way to go.

This lookup type consumes the most system resources, since multiple searches in the destination groups may be performed.

In order to provide more flexibility for creating new products, some of the discount schemes have their own “usage period” for each destination group. This period defines how often the volume discount counter is reset so that the customer starts with the first available discount level. This way the customer gets another pool of “free minutes” or, alternatively, the customer is returned to the standard rate and must send more calls through in order to obtain a discounted rate.

Typically you use the same discount usage periods as the customer’s billing cycle (so his free minutes “reset” when an invoice for the previous period is generated).

It is possible to apply usage periods that do not match billing periods: for example, 10 free minutes of calls to mobiles per day while the customer has a monthly billing cycle. Another common example is a “fair usage” policy for Internet access: although the user is not charged for the total amount of data transferred during a month, only 1GB of data is allowed to be downloaded per day, following which the bandwidth is severely limited.

If at the end of the usage period (e.g., at the end of the month) there is unused traffic left (i.e. minutes, Internet traffic, messages, etc.), it can be rolled over to the next usage period.

For example, a customer has signed up for 100 bundled monthly minutes of free calls to Canada. By the end of the month, only 90 minutes have been used up. The 10 minutes remaining are rolled over to the next month, so during the next month 110 free minutes will be available for the customer.

The following example illustrates how rollovers work:

You create a discount rule with two rollovers and a monthly usage period. The unused traffic left over from the first month is rolled over to the second month and if not used completely, to the third month (two rollovers). If unused traffic is not completely used by the end of the third month, it expires.

If unused traffic from two or more usage periods is rolled over to the next one, the quota with the earliest expiration time is used first. Note that unused traffic cannot be rolled over more than three times.

A volume discount plan can be applied to the following entities:

1. Main product. For better management, you can associate a volume discount plan with a certain product. This volume discount plan will then be applied by default to every account using this product.
2. Add-on product. There is an option for assigning a volume discount plan to an add-on product. When several add-on products with volume discount plans are assigned to an account, the volume discount plans are sorted according to the add-on products’ priority.
3. Customer. Volume discount plans may also be assigned at the customer level. In this case, they would apply to the services consumed by any of the customer’s accounts.
4. Account. You may directly assign an individual volume discount plan to a particular account.

If the account and the customer both have volume discount plans assigned for the same service and destination group and with the same threshold type, the discount plans are sorted according to their priorities. The priority is determined as follows (from the highest to the lowest):

• Volume discount plans assigned directly to an account.
• Volume discount plans assigned to an add-on product.
• Volume discount plans assigned to the main product.
• Volume discount plans assigned to a customer.

The volume discount plan with the higher priority in the list defines the way the next applicable volume discount plan with lower priority will combine with it.

The following example will help clarify how it works:

An account has a list of volume discount plans: one plan is directly assigned to an account, another is assigned via an add-on product and the last one is assigned via the main product. Thus, a volume discount plan assigned directly to an account takes the highest priority and defines how a volume discount plan added via an add-on product is combined with it. Then the volume discount plan that’s assigned to the account via the add-on product, in turn, defines the way the volume discount plan that was added via the main product is combined with it. If any one volume discount plan applicable to a session is used up, the remaining volume discount plans are combined following the same rule.

There are several ways that discounts can be combined with each other. These are defined within the Combine with other discounts list and can be one of the following:

• Never
• Always
• When discount lower than 100% is active
• After reaching the last threshold limit

This mode of combining provides full override. It implies that a higher priority volume discount plan prevents the use of all lower priority ones. This means that even if the higher priority one is used up, the lower priority volume discount plans are ignored.

Using this mode of combining, discounts are summed up to 100% (there is no money back for a consumed service). For example, two 30% discounts will result in a 60% final discount; 70% + 40% discounts will result in a 100% final discount; 100% + 30% discounts will result in a 100% final discount.

This mode of combining is also applicable to discounts that have different priorities. For example, the volume discount plan Premium provides a 20% discount for calls to the USA and is assigned to an account (the highest priority). The volume discount plan Basic provides a 10% discount for calls to the USA and is assigned to the customer (the lowest priority). To apply both discounts to the end user simultaneously, the volume discount plan Premium must have the combination mode Always applied to it since its priority is higher. If it does, the user can make calls to the USA using a 30% discount (20% + 10%).

In contrast to the Never mode of combining, the Always mode only applies to a volume discount plan that follows according to priority. For example, let’s add another volume discount plan to the previous example. The Standard volume discount plan provides a 50% discount for calls to the USA, has the combination mode Never and is assigned to the add-on product. Thus, its priority is lower than Premium, but higher than Basic. Altogether, the user’s discount will be 70% (20% + 50%), and the 10% discount will never be applied.

If a higher priority volume discount plan has a threshold with a 100% discount defined within it, only this volume discount plan is applied to a session until the 100% discount threshold is used up. Only after the volume of the consumed service exceeds the 100% discount threshold can the rest of the discounts be applied. If discounts defined in both the higher and the lower priority volume discount plans are applicable to the same call, they are summed up to 100%. For example, Germany discounted calls by 100% exclusively for 50-minute calls only are followed by a 50% discount for 1000-minute calls, while another discount for the EU offered a 30% discount. The EU discount would only become applicable if the 50 minutes are completely used, and then for a call to Germany, the total discount will be 30 + 50 = 80%.

A higher priority volume discount plan prevents the use of lower priority ones until its “unlimited” threshold is reached or the last (i.e. biggest) threshold is exceeded (regardless of discount value). For example, calls to Germany, discounted by 100% exclusively for 50 minutes are followed by a 50% discount for 1000 minute calls, while another (lower priority) volume discount plan for the EU offered a 30% discount. For calls to Germany the EU discount would only become applicable if the full 1050 minutes are used.

Let’s have a look at the following example:

Your customer has account number 12126505550 in PortaBilling. This account is assigned the main product that sets the rates (so that calls to the US&Canada cost $0.2/min) and two add-on products with different priority levels. Each add-on product includes a volume discount plan:

• A 50% discount on calls to the US for the first 60 minutes (add-on product with a high priority level; method of combining after reaching the last threshold limit).
• A 100% discount on calls to US&Canada for the first 20 minutes (add-on product with a medium priority level).

The account number 12126505550 makes the next calls:

1. First, to Canada – for 15 minutes – it is charged using the “US&Canada” volume discount plan and comes to $0.0.
2. Then, to the US – for 20 minutes – it is charged using the “USA Cheap” volume discount plan (since it has a higher priority level) and comes to $2 (20 * 0.2 * 50%).
3. Finally, to Canada – for 10 minutes – it is charged using the “US&Canada” volume discount plan, but only for 5 minutes which comes to 5*0 = $0.0, and then for 5 minutes without a volume discount plan which comes to $1 (5*0.2).

This functionality allows the service provider to offer a flexible product portfolio that can be custom-tailored to market requirements and increase revenue via the sale of a la carte monthly calling plans.

If service is used during an incomplete billing period (e.g., customer signs up on April 20th and there are only 10 days left in the April billing cycle) then the volume discount thresholds can be prorated according to the duration of the period when service was actually used.

Let’s consider a few usage examples:

• Regular discounts – a volume discount plan offers no discount for the first 100 minutes, a 10% discount for up to 200 minutes and a 20% discount after 200 minutes. The volume discount plan has a weekly usage period. If a user signs up for this plan on Wednesday then the first threshold is 71 minutes and the second threshold is 143 minutes since only 5 days remain in the current usage period. Thresholds are then 100 and 200 minutes for the next week and thereafter.
• Change of volume discount plan – let’s say Richard Roe switches over to a new product on November 15th that has a quota of 100 minutes. Richard receives 53 minutes (100*16/30=53) of free calls for November.

Pay attention to how a volume discount plan is prorated when assigned on the last day of a current billing period:

• before 10:59 PM – services are available during the entire day. The quota is prorated, bringing the available amount of services for the whole day;
• after 11:00 PM – services are unavailable till midnight. The quota is prorated when the following billing period begins.

With this feature you can provide your customers with correct billing for incomplete volume discount usage periods, thus preventing your business from revenue losses.

You can change a volume discount plan and preserve its counters for a new volume discount plan. This enables you to provide a single continuous offer to your end users with the option for adjusting/updating it at any time. To preserve the counters, ensure that both volume discount plans satisfy the following conditions:

• A destination group is identical and belongs to the same destination group set (e.g., both volume discount plans apply to the US & Canada destination group from the North America destination group set).
• Identical service (e.g., for both discounts the service is defined as Voice Calls).
• Identical threshold type (e.g., the provided discounts are based on the session cost).
• Identical usage period (e.g., both discounts have one-time usage or are reset monthly).
• The Prorate thresholds for first usage period option is enabled or disabled (e.g., when assigned in the middle of a billing period both discounts are recalculated depending on the number of days left until the end of the current billing period).
• Both volume discount plans must have the same priority level (e.g., the previous and new volume discount plans are associated with the main product or add-on products at the same priority level);
• The volume discount plan change must be done as a single operation. To do this, remove the old volume discount plan, assign a new one and click Save. Note that when you change the volume discount plan via an add-on product, you can:
  • Schedule when the new add-on product will be activated. PortaBilling will replace the active add-on product with the new one on the stated date.
  • Replace the already active add-on product with the new one. PortaBilling applies the volume discount plan that’s defined in the new add-on product at once.

If all conditions are met, the counters of the previous volume discount plan are preserved for use with the new one. Otherwise, PortaBilling resets the counters. The following examples represent how changing the volume discount plans works when the counters are preserved:

The service provider offers two bundles – 50 and 100 free domestic SMS messages with the identical pre-condition: valid after sending 25 SMS per month without a discount. A user subscribes to the 50 free SMS bundle. He has already sent 25 SMS without a discount plus 10 SMS out of 50 available and wants to upgrade to 100 free domestic SMS messages this month. He switches over to a new SMS bundle and since he has already sent 35 SMS messages, 90 (100-10) free domestic SMS are available for him immediately after the volume discount plan change.

A user uses up 9 GB and switches over to a new 7 GB product. He is not able to browse the Internet until the end of the month and starting from next month, he will only have a 7 GB Internet traffic quota available. The newly assigned volume discount plan will show the status Used in Full until it is reset.

Let’s say that in addition to a Mobile Services product you offer both 2 GB and 4 GB Internet quotas via your add-on products. These add-on products have the same priority and are conflicting.

A customer who already has a 2 GB quota decides to call customer service and upgrade the quota to 4 GB.

When you assign an add-on product that has the same priority, PortaBilling suggests that you:

• Replace the already active add-on product with the new one. PortaBilling applies the volume discount plan that’s defined in the new add-on product.
• Schedule when the new add-on product will be activated. PortaBilling will replace the active add-on product with the new one on the stated date.

Note that volume discount plan counters will be preserved during the product change.

You can see the reasons for the add-on product conflict. Just click the  arrow to the right of Details of the add-on product conflict.

If a volume discount plan is changed/assigned before 10:59 PM, the day of change/assignment is included in the proration for the newly assigned plan. Let’s consider when a volume discount plan is:

• changed in the middle of a billing period; or
• assigned on the last day of a billing period.

Consider these examples when counters for the previous volume discount plan are preserved for use with the new one.

• Mary Smith is granted 60 minutes of free calls. By November 15th she wants to upgrade to a new quota of 100 minutes. She switches over to the new product and since she made 20 minutes’ worth of calls during 14 days, there are still 8 minutes (60*14/30-20=8) available from the previous quota. The newly assigned quota is prorated for the 16 days left till the end of the month (100*16/30=53). With the unused minutes from the previous quota added, Mary receives a total of 61 minutes (8+53=61) of free calls for November.
• Mark Johnson does something similar. He made 59 minutes’ worth of calls (almost the whole quota) during 14 days, so 31 minutes (60*14/30-59=-31) would be deducted from the new prorated quota (100*16/30=53). Thus Mark only has 22 minutes available (-31+53=22) till the end of November.

If a volume discount plan is assigned on the last day of a current billing period:

• before 10:59 PM – services are available during the entire day. The quota is prorated, bringing the available amount of services for the whole day;
• after 11:00 PM – services are unavailable till midnight. The quota is prorated when the following billing period begins. For instance, John Doe has a monthly billing period. At 6 p.m. on April 30th (the last day of his billing period) he assigns an add-on product that contains a quota of 100 minutes of free international calls. As a result, John receives 3 minutes of free calls (100*1/30=3), since the quota was prorated for the last day.

To change a volume discount plan using the API, use the following methods:

• To change volume discount plans included in the main product use the i_vd_plan property in the Update_product method;

• To change volume discount plans for a particular customer use the i_vd_plan property in the Update_customer method;

• To change volume discount plans associated with add-on products use the assigned_addons structure in the Update_account method. When using this method, the assigned_addons structure must contain the complete list of add-on products applicable to an account (i.e. the add-on products that will not be changed plus new add-on products that must be assigned to an account).

Please refer to the PortaBilling XML/JSON API Reference Guide for more information about API methods.

By default, volume discount plans are applied irrespective of peak and off-peak periods, i.e. a minute is always counted as a minute. It is possible to create a volume discount plan with a different structure of discount thresholds for peak and off-peak time (and even for first and second off-peak periods). In this case, only counters for the relevant portion of the volume discount plan will be modified, based on the time when the service is used.

It is possible to configure the system so that a customer crossing a discount threshold (where a new discount level is applied) would automatically receive a notification. This could be used to notify the customer that he is either approaching the end of his discount provisioning or is now out of free minutes, or inform him that he is now eligible for a higher discount.

You can notify your customers that they are reaching the threshold for when a current discount stops being provided to them.

When a consumed volume of service reaches its warning threshold, as defined by an administrator for a particular discount, a corresponding notification is delivered to the customer by email or SMS.

Consider the following example:

A customer wants to sign up for 200 free minutes of calls to Canada. Moreover, he asks to be notified when he is down to only 20 free minutes. An administrator creates a volume discount plan for him that provides 200 minutes of free calls for Canadian destinations and then configures the requested customer notifications: to inform him when he has used up 180 minutes and again when the whole 200 minutes are used up.

Then he assigns this volume discount plan to the customer’s account. When the customer has used up 180 of the 200 minutes for outgoing calls, he is notified by email accordingly.

Sending threshold notifications to your customers gives them a clear idea of the amount of services consumed and other charges. And it may also encourage them to buy additional discounted service bundles, thus raising your sales revenue.

It may happen that a session (e.g., voice call or broadband Internet connection) spans several discount thresholds. For instance, a volume discount plan provides 100 free minutes of calls per month, after which the regular rate ($0.10/min) is charged.

The customer has used up 98 minutes already, and then makes a phone call which lasts for 8 minutes. In this case, the first two minutes of this call are covered by the 100% discount and the normal rate applies to the remaining six minutes.

By default, an aggregated discount is calculated based on the rates/discounts applicable for each individual portion of the session and the duration of each portion. In our example the aggregated discount is: 100% * (2/8) + 0% * (6/8) = 25%. A call is then charged based on the total duration, the discount is applied and a single xDR is produced. In this case the amount charged for is: 8 minutes * $0.10 – 25% = $0.60.

A single xDR record makes it a bit more difficult to understand how the charges are calculated, but it correctly reflects the fact that the customer only used the service once.

If the Split xDRs option is activated for a particular discount level in the volume discount plan, then a session that crossed a threshold will produce multiple xDR records, each linked to the applicable discount level/rate.

In our example it is:

• xDR #1: 2 minutes * $0.10 – 100% = $0.0;
• xDR #2: 6 minutes * $0.10 – 0% = $0.60.

As you can see, the total amount charged is the same in both cases ($0.60); it is just a question of which xDR presentation is better for your end users.

Transfer of funds and airtime among end users is a very popular service, especially in countries where payment systems are scarce. Money transfers provide a fast and convenient way to pay for everything without cash and/or credit cards.

With the transfer of funds and airtime feature, end users are able to:

• transfer their available funds to pay for goods and services; and
• share airtime from their service wallets with friends and family.

End users can take advantage of this service via their self-care interface. They can select what to transfer: either money or airtime (minutes, SMSs, GB, etc.) from their service wallet. Then they enter the recipient’s phone number (it must be predefined in the Phone field, see Implementation specifics section). For security purposes, each time a user initiates a transfer, the system sends an email or an SMS with a verification code. This code expires in 3 minutes and becomes invalid after the 3rd ineffective attempt to enter it. This is a safety provision to protect users from unauthorized persons obtaining access to verification codes.

As soon as an end user inputs a verification code to the system and the operation is successful, funds or airtime are transferred to the recipient.

Let’s consider a transfer of funds and airtime, separately.

To prevent fraud, an administrator only enables the transfer of funds for an individual customer or a customer class.

End users who have credit accounts (with individual credit limits) or debit accounts can transfer their available funds from their self-care interfaces. This is very convenient, since it encourages them to manage their funds efficiently, and be ready to either top-up their relatives’ balances or pay for goods in a shop.

For instance, let’s say the user Richard Roe has $50 worth of available funds. He decides to transfer $35 to pay for goods in a grocery store. Richard Roe visits his self-care interface, enters the phone number of the grocery-store owner and the amount of money to be transferred – $35 in this case. He receives an SMS with a verification code and immediately enters that into the system. The system accepts the code and funds are withdrawn from his account. The grocery-store owner receives $35 and Richard’s available funds are now $15.

If an end user makes a transfer by mistake, an administrator can reverse the transaction.

Transfer of airtime involves the transfer of the contents of any service wallet – minutes for calls, SMSs, GB of Internet traffic, etc. The transfer is only allowed among end users having identical volume discount plans. This is a safety measure to prevent service abuse (e.g., when end users sign up for cheap products and then transfer airtime to use for premium products or commercial purposes).

Service providers encourage end users to make frequent top-ups to provide for the transfer of airtime.

For instance, Jane Smith and her friend have identical service wallets that include Voice calls and Internet traffic. As the friend spent all his service wallet balance on Internet traffic, Jane Smith transfers 2 GB so they can continue chatting via the Internet. Afterwards, Jane finds out that her own service wallet ran out of money too, so she tops up her service wallet.

End users may create a favorites list that includes recipients they are accustomed to cooperating with. The list is easy to manage, and transferring funds and/or airtime can be done with just a few clicks. This saves time and makes the transfer process more user-friendly.

For example, returning to Richard Roe, let’s say he visits the grocery store every week and pays for his goods by transferring funds. To have the grocery-store owner’s contact information at hand, he includes it in his favorites list. Next time he goes grocery shopping he just selects the owner’s account from the list and transfers the money. It’s that simple and efficient.

In general, the transfer of funds and airtime feature has the following implementation specifics:

1. Both sender and recipient must be allowed to transfer funds.
2. Only debit and credit accounts with individual credit limits can transfer and receive funds.
3. To allow accounts to transfer and receive funds, enable this option either at the customer or customer class level.
4. The currency of the sender and recipient must be the same.
5. Only accounts with identical service wallets can transfer and receive airtime.
6. To allow airtime exchanges, enable this option within the service wallet.
7. On the account self-care interface, the sender can find the recipient:
   • by the recipient’s account ID;
   • by the recipient’s phone number – the administrator must predefine the phone number in the Phone field (Personal info > General info > Address info tab) or the recipient must define their phone number themselves on their account self-care (Contact information > Phone field).

This solution enables service providers to increase their revenue by encouraging their end users to frequently top up their service wallets and their main balance to be ready for transferring money to their families and friends. Since no payment system is required to transfer funds and/or airtime, the service is widely used.

In addition to being an easy and secure way to pay for goods and services it encourages users to register new accounts. Thus, service providers also expand their customer base.

CSPs can allow their users to transfer airtime among their service wallets and quotas in such forms as GB, minutes, SMSs and money, etc.

Since the way that users transfer airtime may differ, the transfer is performed via the API. To do that, CSPs must develop custom self-care portals or mobile apps.

Consider the following specifics:

• The lifetime of transferred airtime synchronizes with the lifetime of the recipient’s service wallet/quota.
• The transferred airtime is always used up first.
• To allow airtime transfer, enable this option within the service wallet/quota for both sender and recipient.
• The measured volume of service wallets/quotas must be identical (e.g., GB, minutes and money).
• Both sender and recipient must have the service wallet/quota assigned either to the product or directly to their accounts in PortaBilling.

For instance, let’s say that John Doe has 2 GB rolled-over quota from the previous month that expires on August 10. John opens his custom self-care interface and transfers these 2 GB to Mary’s service wallet. Now Mary can use this quota until her service wallet expires, on August 28. Both John and Mary receive email notifications about the successful transfer.

To transfer airtime among service wallets and quotas using the API, use the make_transaction method of the Discount plan information service. For more information refer to the PortaBilling JSON API Reference Guide.

With this feature, users can manage the airtime they’ve paid for and use it in full. This increases their loyalty and makes CSPs more competitive in the market.