Start accepting card payments sooner and with less effort using Stripe
You can now start accepting card payments on your custom self-care portal much sooner and with less effort by using a new payment flow supported by Stripe.
Service providers that process card payments must comply with the Payment Card Industry Data Security Standard (PCI DSS), a set of security requirements designed to protect cardholder data. If card details are going to pass through a service provider’s IT systems, payment processors generally require extensive PCI DSS validation before the provider can start accepting payments.
With this release, your custom self-care portal can use an embedded Stripe form that sends the data directly to Stripe. Because the card details don’t pass through your systems, you may qualify for a much simpler PCI DSS validation process in the form of a short annual self-assessment questionnaire.
If customers choose to save their card, Stripe stores the card details, and PortaBilling receives and stores a token that lets it charge the saved card automatically for future invoices.
Your developers will need to embed the Stripe form in your custom portal. The CloudPBX Self-Care Portal and Mobile Account Self-Care App/Portal will support payments through the Stripe form in the future.
What’s improved?
Faster launch of online payments
Start accepting card payments sooner, without spending time and resources on full PCI DSS validation.
Find more details here.
Send eInvoices to EU customers
You can now send business customers electronic invoices (eInvoices) that comply with the EU’s eInvoicing standard, EN 16931, using the new eInvoicing (Storecove) module in the Add-on Mart. Unlike PDF invoices, eInvoices contain structured data that can be processed automatically by a customer’s ERP and accounting systems.
Compliance with EN 16931 is becoming increasingly important as eInvoicing requirements expand across the EU. Public-sector organizations in the EU are already required to accept eInvoices that comply with this standard. By 2030, EN 16931 eInvoices will also become mandatory for cross-border B2B invoicing within the EU, and some countries are introducing these requirements even earlier.
This new module passes invoice data from PortaBilling to Storecove, which generates an XML that is compliant with EN 16931 and country-specific requirements. Storecove then delivers the eInvoice through the Peppol network, directly to the customer’s ERP or accounting system.
The module works with regular and on-demand invoices (initial, midterm, and out-of-turn). Admins can enable eInvoicing for either a customer class or an individual customer, track each eInvoice from submission to delivery, receive notifications when generation or delivery fails, and resubmit failed eInvoices with one click.
What’s improved?
Readiness for EU eInvoicing mandates
Serve EU business and public-sector customers that require structured electronic invoices.
Faster invoice processing for customers
Customers can save time processing invoices and avoid errors from manual data entry.
Find more details here.
Send carrier-specific response codes for rejected calls
When a carrier sends you a call for termination, and your network rejects it (for example, because the called number is busy or not in use), the carrier relies on the SIP response code to decide what to do next. Based on this code, its system may play its own announcement to the caller (e.g., “This number is not in service”) and stop trying to place the call; or try another route (if it seems to be just a temporary issue with call delivery through your network).
Previously, when PortaSwitch rejected a call from a carrier, voice prompts would announce the rejection reason, but the SIP response code remained the same (403) for most rejected calls. In carrier-to-carrier traffic, voice prompts are often disabled, so the originating carrier couldn’t process rejected calls properly.
Now, you can define which response codes PortaSwitch sends for specific call rejection reasons. Because different carriers may expect different codes for the same reason, you can configure response codes separately for each carrier.
Example
Carrier A and Carrier B send calls to Owl Telecom’s DID number range, where not every number is assigned to an account. For unassigned numbers, Carrier A expects 404 Not Found, while Carrier B expects 480 Temporarily Unavailable. Owl Telecom’s admin configures the required response code for each carrier. Now, when either carrier sends a call to an unassigned number, PortaSwitch rejects it with the code that carrier expects, and the carrier stops trying other routes.
What’s improved?
Better relationships with partner carriers
Meet SIP response code requirements and get fewer support requests from carriers.
Find more details here.
Web interface changes
Redesigned Product page
The Product page has been redesigned to help admins find and manage products faster:
- Search parameters have moved from the left side panel to a single row at the top, so all columns fit on the screen without horizontal scrolling.
- Admins can look up rates, clone, and delete products using the Actions column, consistent with other pages in PortaBilling.
- The product list and product group list are organized into two tabs on a single page.
- All settings are available on the creation panel, so admins can fully configure a product without reopening it after creation.
- When adding a charging rule that defines which tariff to use for a service, admins can select from the most frequently used access codes from a predefined list, reducing the risk of typos. These codes determine which tariff applies to different call types, such as incoming, outgoing, and forwarded calls.
- When editing a product, admins can access settings grouped into tabs instead of opening separate sliding side panels.
- In the left menu, admins can see at a glance how many services of each type the product includes, without opening every section.
- The Audit log button has moved to the top bar instead of being hidden in entity-specific menus, so admins can quickly check who changed a product and when.
What’s improved?
Easier administration
Admins can manage products in fewer steps.
Find more details here.
Share readable log extracts without manual reformatting
Admins often copy parts of billing and SIP logs to investigate an issue or share it with colleagues. Now, the copied text keeps its structure: each log entry starts with its date, time, and log level, followed by the message on the same line, and multi-line entries keep their layout. This makes log extracts easier to read and scan for relevant information. Admins can paste them directly into tickets, chats, or emails without manual reformatting.
What’s improved?
Faster troubleshooting and collaboration
Teams spend less time reviewing logs and investigating issues.
Find more details here.
Troubleshoot private calls with access to actual phone numbers
When a caller hides their number or a called number is masked for privacy, admins may still need the actual numbers to investigate call issues.
Now, admins can see the actual caller (CLI) and called (CLD) numbers of private calls on the Trace session page. Previously, the page displayed “Private” instead of the caller number and masked digits of the called number.
Private numbers are now displayed in grey italics, with a tooltip indicating that privacy settings apply. This helps admins identify the actual phone numbers while knowing which ones were hidden during the call.
By default, all admins with access to the Trace session page can see these numbers. You can restrict this for specific roles, so their users see “Private” and masked digits, as before.
What’s improved?
Easier troubleshooting of private calls
Authorized admins can identify the actual caller and called numbers when investigating issues.
Find more details here.
