Arbital / Integrated operating platform
The software
that ran an ISP
Connect a customer's service, the business workflow and the network that delivers it.
One business, connected through software
Running Arbital meant keeping customer records, installation work, billing and network access in step. I built and led development of an integrated operating platform, primarily in PHP, that connected those parts of the business.
The platform extended UTM5, the billing engine, through its interfaces and joined billing state with our own customer, building, device and workflow records. Employees could work through the subscriber's service context, while software carried the changes into the systems delivering it.
From an installation request to an active service
An employee started subscriber activation. The application created the customer and account in UTM5, established the billing period and tariff, and configured the Internet service with its IP and MAC identity.
The same workflow then looked for the installation request matching the building and apartment. One unambiguous match could be closed automatically. If several requests matched, the application presented them for staff to resolve.
The workflow connected a commercial event to its operational state: who the customer was, which service they had, how the network identified them and whether the installation work was complete. The employee initiated activation; the platform coordinated the backend operations.
Reconcile a payment across independent systems
A payment callback arrived with a provider's transaction identifier. The application checked that identity against its pending and completed records and the transactions already recorded in UTM5.
That comparison let the handler recognize an existing billing transaction and reconcile its local completion and billing-reference fields. When a new payment was needed, it called the billing interface, stored the result and sent the customer notification after success.
The integration made external payment identity, local processing state and billing state part of the same workflow. It included duplicate checks and recovery paths for records that needed reconciliation.
Turn subscriber policy into network behavior
Customer and tariff records also supplied the desired network policy. A reconciliation daemon compared active and blocked subscriber sets with shaper tables and access-control lists, then applied the differences through device connections.
Shared adapters handled the command and configuration differences across switch families. The application selected an adapter from device metadata and used common operations for configuration, MAC queries, diagnostics and saving changes.
For traffic shaping, software calculated separate incoming and outgoing coefficients from observed activity and adjusted tariff-specific IPFW pipe rates. For subscriber identity, it compared authorized IP/MAC bindings with observed ARP state, installed restrictions for violations and removed corrected or expired blocks.
Keep decisions and execution connected
Staff actions and automated reconciliation had different roles. Employees initiated activation and selected operational changes; software performed the backend steps and reconciled subscriber policy with network state. Ambiguous installation matches stayed visible for a person to decide.
Customer records, billing, staff workflows and network access in one operating platform.
These are selected workflows from the broader system I built and led at Arbital.Read the wider Arbital story, from the first customer to network architecture, service launches and production recovery.