What’s new in MR131

With this release, admins and resellers can spot Add-on Mart modules (such as payment gateways or new CPEs) right on the PortaBilling pages they are working on, without switching to Add-on Mart for a separate search. This allows service providers to offer customers the functionality enabled by a module as soon as they need it (e.g., adding auto-provisioning for an IP phone model that a customer has been asking for).

Previously, admins and resellers could not tell whether a suitable module existed without opening a separate page in the Add-on Mart portal, which meant they could overlook modules that matched their business needs.

Now, PortaBilling displays a promo card for the Add-on Mart module on the page where the corresponding functionality is configured. The card includes a short description of the module, its current status (e.g.,  available for a free trial, subscription, or already subscribed to), and a link to the module’s page in the Add-on Mart Management Portal.

Currently, admins and resellers can see relevant Add-on Mart modules during the following actions:

• Creating a payment system
• Creating a CPE profile for a specific IP phone model
• Adding an IP phone to the CPE (Customer Premises Equipment) inventory
• Enabling a taxation plug-in
• Configuring invoicing
• Creating an invoice template using the external visual editor
• Configuring account call recording

Clicking a link on the promo card redirects the admin or reseller to the Add-on Mart portal, where subscription, payment, and module configuration remain fully managed.

• Admins and resellers spend less time checking for suitable modules.
• Service providers start using the functionality that fits their business needs sooner.

• Promo cards are available only in the admin and reseller portals.
• The service provider must sign up for Add-on Mart and connect it to PortaBilling using Add-on Mart credentials.
• To reflect changes to the Add-on Mart module status (e.g., after subscribing), the page must be reloaded.

Service providers that offer data plans to IoT/M2M customers often allow multiple SIM cards to share a single data pool. Instead of managing a separate allowance, e.g., 10MB/month for each SIM card, a customer gets a single shared pool that covers the combined volume of N eligible SIM cards (N is the arbitrary number assigned by the admin). This allows devices with lower usage to offset those with higher usage, cutting unnecessary excess-usage charges. For example, a logistics company may equip its delivery vehicles with SIM cards for GPS tracking. Some vehicles may travel much more than others and therefore consume more data. With a shared data pool, vehicles with lower usage leave more of the allowance available for vehicles with higher usage, helping the company avoid excess usage charges as long as data remains in the pool.

With this release, a new Customer pool, renewable by calendar bundle type, is introduced, which lets you create and manage shared pools directly in PortaBilling. The shared pool is created based on the service volume and the number of participating SIM cards. For example, a 10 MB service volume with 10 participating SIM cards creates a 100 MB shared pool. Adding or removing SIM cards does not change the shared pool. If 5 more SIM cards are added, all 15 SIM cards share the same 100 MB pool. PortaBilling automatically tracks usage for each participating SIM card and deducts it from the customer’s shared pool. Large-capacity data pools can now support much higher usage volumes without workarounds, ensuring accurate usage tracking, notifications, and rating as your IoT/M2M business grows.

Customers can manage their shared pools through the IoT and M2M Portal (available via the Add-on Mart) or your custom self-care portals built using the PortaBilling API. When the shared pool is exhausted, PortaBilling can notify an external system, such as an IoT device management platform, allowing you to implement custom business logic such as alerting the customer that they’ve used up their monthly data plan and offering to top it up or triggering other automated actions.

• Service providers offer competitive data pools.
• Customers save money by sharing one combined data allowance across SIM cards and managing their usage in one place.

• One data pool can be assigned to a customer at a time. New Customer pool, renewable by calendar bundle cannot be assigned directly to accounts and products.
• Adding or removing SIM cards from the pool does not change the total volume in the shared pool. For example, a 10 MB pool shared by 10 SIM cards remains 10 MB when 5 more SIM cards are added.
• To increase service volume in the shared pool, assign a new data pool with a larger number of participating accounts to the customer.
• Service volume can be prorated, so when a data pool is assigned for a customer in the middle of a billing period, its service volume is adjusted to the remaining part of the period. This adjustment is applied at the customer level and does not depend on the number of participating SIM cards.
• Data pools are unavailable for resellers and their subcustomers. This functionality is intended for a future release.

Find the configuration details here.

SIM cards contain sensitive information such as PIN and PUK codes and cryptographic keys used to authenticate subscribers on the mobile network. If this data is exposed to the wrong person, it can be used to clone a SIM card or gain unauthorized access to services.

PortaBilling now protects this data in two ways:

• Restricting who can access the sensitive SIM card fields via the web interface and API
• Encrypting it in the database

By default, only an admin with the Root role can view sensitive SIM card data via the web interface and API; other users need explicit permission. Even with this permission, an admin must manually reveal each field, which remains visible for only a few seconds. This helps prevent accidental exposure of sensitive data (e.g., during screen sharing).

Database encryption of sensitive SIM card data is disabled by default. You can enable it so that this data remains protected even when applications, such as a custom tool used to generate sales reports, have general read-only database access. This prevents anyone who can access the database through such applications from reading sensitive SIM card data, which is otherwise restricted in the web interface and API. Once encryption is enabled, PortaBilling starts encrypting existing SIM card data in the background while automatically encrypting data for all new SIM cards.

Service providers can meet security requirements for SIM card data.

• Sensitive SIM card data fields are: PIN, PUK1, PUK2, Authentication key, OPc key, AMF, and activation code.
• When access to sensitive SIM card fields is restricted, the API does not return those fields. If you’re updating your system to MR131 or later and use custom integrations that require these SIM card parameters to be included in the API, make sure to explicitly enable access to these fields in the relevant roles.
• You can grant permission to view sensitive SIM card data to custom roles of the Admin, Reseller, or Customer self-care type. Granting this permission to a Customer self-care role affects the API access only.
• When encryption is enabled, new SIM cards (uploaded or added manually) are encrypted immediately. Existing SIM cards are processed by a background task that runs once per hour, so encrypting a large SIM card base may take some time.
• Disabling database encryption runs the same background task in reverse, decrypting the sensitive data back to plain text.

Find the configuration details here.

Setting up xDR import involves two sides: a vendor side (to reflect the cost) and a customer side (to charge your customers for service usage). Previously, xDR import setup required creating a vendor record even when there was no vendor in the traditional sense (e.g., when calls went through a mobile carrier’s network). As a connection used purely for xDR import didn’t route any traffic, some fields still required placeholder values just to save the connection.

Now, configuring vendor connections for xDR import is more straightforward:

• A Capacity value is no longer needed. The only exception is a voice call connection that uses utilization-based routing.
• Connections for the messaging service can now use the Generic connection type, so there’s no need to set up a service policy.

  

For detailed configuration steps, see the xDR import configuration.

Setting up xDR import connections takes less time and causes less confusion.

The pages for Code groups and Code group sets have been redesigned to make their configuration easier and unify it with the rest of the PortaBilling web interface.

Code groups let admins group rate codes that should be treated the same way (for example, codes 38050, 38066, etc. are placed under “UA-Vodafone”) when defining the pricing. When configuring a tariff with this code group set assigned to it, you can select the “UA-Vodafone” code group when adding a rate. PortaBilling applies the same rate to all rate codes included in that group. Code group sets organize these groups into different sets based on the required granularity and other business requirements. For example, for your mass-market products, you need a code group set called “Retail” which operates on high-level groups such as “North America,” “EU”, etc. to configure bundles such as “1000 free minutes of calling to Europe”. For your SIP trunking customers or when dealing with wholesale VoIP minutes, you will probably need groups like “UA-Vodafone” since pricing for other mobile operators in Ukraine may differ.

The redesign includes the following changes:

• Search parameters have moved from the left side panel to a single row at the top, matching the layout of other pages. Admins can now filter code group sets by the rate match mode and see the number of code groups created in each set.

  

  The same applies to code group search parameters, which have also moved to the top.

  

• Managing a code group set now follows standard web interface behavior: admins edit and delete a code group set via buttons in the Action column.

  

  Code groups within the code group set page follow the same behavior.

  

• When creating a code group set and a code group, all required settings are available on a single panel organized into tabs. This lets admins complete the configuration for the code group set and its code groups during creation, without reopening either afterward.

  

  

• The Audit log button is now located at the top bar, next to Notifications and Help.

This release introduces a redesigned Customer class page, making it faster for admins to search and manage customer classes:

• Search parameters have moved from the left side panel to a single row at the top, matching the layout of other pages. Less common search parameters are grouped under the More menu. This release also adds the ability to filter customer classes by currency and taxation plug-in.

  

• Managing a customer class now follows the standard web interface behavior: admins edit and delete a customer class via the buttons in the Action column.

  

• When admins create a customer class, all additional settings appear on a single panel organized into tabs. Admins can complete the configuration during creation, without reopening the customer class afterward.

  

• Submenus that used to open in sliding side panels are now grouped into tabs. Tabs use the full page width and show more items at once, reducing both clicks and scrolling.

  

Admins spend less time navigating between pages and panels while managing entities.