Network access  /  Subscriber control

Your billing runs the network.

ISPCQ drives the IPACCT NAS straight from the customer’s contract — provisioning, plan changes, the paid-through window and IPACCT’s tolerance grace, all from one record. The contract is the single source of truth for the account on the NAS.

Contract-driven IPACCT NAS Tolerance grace Live usage in-contract Account lifecycle Roadmap: RADIUS / MikroTik
The problem

A billing system and a NAS that don’t talk drift apart.

Most setups run billing in one system and subscriber control in another. They sync on a timer, or by hand. A customer pays, but the NAS hasn’t heard about it for an hour. A plan changes in billing, but the profile on the network lags a day behind. A support agent reads “active” while the subscriber sits offline. Every gap between billing and the NAS is a support ticket waiting to happen.

ISPCQ closes that gap by making the contract the source of truth for the NAS. Activate, change, suspend or restore on the contract, and the IPACCT NAS follows. Read the customer’s live usage, account state and tolerance countdown without leaving the contract. One record drives the network; the network reports back to the same record.

Capabilities

The IPACCT NAS, driven from the contract.

Seven layers of contract-to-NAS integration, built on IPACCT — the deep, production NAS integration ISPCQ runs today.

01
Contract-driven provisioning
Subscriber + S-VLAN/C-VLAN over IFMGR

Activate a contract and ISPCQ creates the subscriber on the IPACCT NAS and provisions its service and customer VLANs (S-VLAN / C-VLAN) over IPACCT’s IFMGR API — interface up, bridge port, config saved. The account on the NAS is born from the contract, not typed in twice.

  • Subscriber account created on IPACCT when the contract goes live
  • S-VLAN / C-VLAN and bridge config provisioned over the IFMGR SOAP API
  • Re-provisioning rebuilds a contract’s NAS state from its attributes on demand
02
Plan changes follow automatically
Service package to the NAS · bandwidth at the access layer

Change a customer’s plan and ISPCQ pushes the new IPACCT service package to the NAS for active contracts — no separate edit in the NAS console. The bandwidth profile itself is enforced at the access layer, so speed and package stay in step with the contract.

  • Plan change syncs the IPACCT service package; immediate changes propagate now
  • Bandwidth enforced at the GEPON / access layer, in step with the plan
  • One change on the contract; billing and the NAS stay aligned
03
The paid-through window
Set · extend · enforce

ISPCQ maintains each contract’s paid-through date and syncs it to IPACCT, which enforces the subscription window. Pay, and the window extends; let it lapse, and IPACCT acts on it. Operators can stop or start a subscriber straight from the contract when they need to act now.

  • Paid-through (expiry) date maintained on the contract and synced to IPACCT
  • IPACCT enforces the subscription window the contract defines
  • Operator stop / start reaches the NAS immediately when needed
04
IPACCT’s tolerance grace
A humane grace period, surfaced in-contract

This one is IPACCT’s, and it’s a good one. When a customer’s paid period ends, IPACCT doesn’t cut them dead — a configurable tolerance window keeps a just-overdue subscriber online instead of triggering a needless disconnect and an angry call. ISPCQ surfaces the state right on the contract.

  • Warning → Tolerance → Expired, shown as a badge with a day countdown on the contract
  • A just-overdue customer stays connected through the configurable grace window
  • Staff can grant a +1 / +3 / +7-day extension on the contract in one click
  • Exposed to the customer too, via the portal and the billing API
05
Live usage in the contract view
Real-time bandwidth · traffic graphs · diagnostics

The agent reads the customer’s IPACCT usage without opening the NAS console: real-time in/out bandwidth and daily, weekly and monthly traffic graphs, right in the contract. Network checks — ping, ARP-ping, MAC-table lookup — are a click away on the same screen.

  • Real-time in/out bandwidth and historical traffic graphs from IPACCT, in-contract
  • Ping / ARP-ping / MAC-table (FDB) diagnostics from the contract page
  • Account status — warning, tolerance, expired — at a glance
06
One customer, one screen
NAS + OLT signal + billing + tickets

The NAS is one layer of a single customer view. On the same screen as the IPACCT usage and account state, the agent sees the ONU’s optical signal in dBm, the plan and balance, and the support history — billing, network and support reading from one record instead of three systems.

  • IPACCT usage and state beside OLT optical signal (dBm) and delivery type
  • Plan, fee, promotions and balance on the same contract card
  • Notes, calls and tickets on the customer timeline
07
A unified NAS layer ahead
IPACCT deep today · RADIUS / MikroTik next

IPACCT is the deep, production NAS integration ISPCQ runs today. The roadmap adds a unified NAS layer so RADIUS, MikroTik and other BNG backends can plug in alongside it — the same contract-driven model, more NAS choices, no rip-and-replace.

  • IPACCT (SOAP, two endpoints) in production today
  • A unified NAS abstraction on the roadmap
  • RADIUS / MikroTik / BNG backends to follow, contract-driven all the same
Real-life scenario

A few days late — kept online by tolerance, restored by a tap.

The setup. A customer’s monthly period ends on the 1st and the payment hasn’t landed. Instead of a hard cut at midnight, IPACCT’s tolerance grace keeps them connected. The contract shows a green Tolerance badge with a day countdown, and a warning has already gone out — nobody is sitting in the dark wondering why the line died.

The grace. On day three they’re still online, still inside the configurable grace window. The support agent, looking at the contract, sees exactly where they stand: warning → tolerance → expired, with the days remaining. No guesswork, no “are they cut off or not?”, no logging into a separate NAS console to find out.

The resolution. The customer pays through the portal. ISPCQ reconciles it, extends the contract’s paid-through date, and syncs that date to the IPACCT NAS — the account is back inside its paid window and the badge returns to normal. Had they needed a little more time, the agent could grant a +1 / +3 / +7-day extension on the contract in one click. Nobody got needlessly disconnected; nobody re-keyed anything into a second system.

The NAS  /  Where ISPCQ began

We were built to control IPACCT.

ISPCQ exists because of IPACCT. The operators ran IPACCT as their NAS first, then built the ERP around it to control it — provisioning, billing and the subscriber lifecycle — and grew that into the full operating layer ISPCQ is today. IPACCT is still the NAS we integrate with most deeply: a robust, Bulgarian-built subscriber-management platform, roughly two dozen operations across two SOAP endpoints, from provisioning and VLAN management to accounts, sessions, traffic and the tolerance grace. The depth is the point: this is not a button that opens another console, it is the contract driving the NAS and the NAS reporting back to the same contract.

Tolerance — the grace period that keeps day-late customers online — is IPACCT’s own. ISPCQ reads it, shows it on the contract, and lets staff extend it. The roadmap adds a unified NAS layer so other backends can join, but IPACCT remains the deep, production integration today.

API
SOAP (IFMGR + NAS API)
Operations
~25 across the integration
In the contract
Usage, state, tolerance
Heritage
The founding integration
Roadmap
Unified NAS layer