Browse FAQs by category.

Yes. If a tenant’s service is automatically suspended because the account is past due, you can manually override that suspension and re-enable the account. It stays enabled until the next scheduled suspension date.

When a tenant has an outstanding balance, a red balance bar appears at the top of the tenant account. From there you can re-email all open invoices, assuming the email address on file is current.

Yes. Email addresses can sync between the portal and the billing system so a change made in one place is reflected in the other. That helps reduce missed invoices and support friction caused by outdated contact information.

Yes. If multiple tenant accounts share the same email address when they are first created, they can be tied to the same billing customer account. Changes made on one tenant account do not automatically update every other account sharing that billing record.

No. Direct Tenant Billing is charged monthly based on the actual number of tenants in the system, not simply the maximum tenant tier for that location.

No. API location access fees are not required for Direct Tenant Billing.

Additional address billing is based on the number of additional addresses assigned. Each additional IP is billed according to the configured static-IP structure tied to that service.

Tax rates are created during billing-profile setup, but they are managed through the external billing system. You can also update the TaxRate ID used by a billing profile when you edit that profile.

No. The router fee line item is triggered when a Zero Touch router is assigned to the tenant account. If you are providing non-Zero Touch hardware, that cost needs to be reflected in the service pricing instead.

Any router that supports PPPoE should work for tenant connections, which includes most consumer and commercial routers. Hardware quality still matters, so deployment teams should avoid treating all routers as equivalent just because they support the protocol.

The underlying hardware may be similar, but routers purchased elsewhere do not include Aditum™ provisioning and management software. That means they do not support the same automated Zero Touch behavior inside the platform.

Any change to a tenant account triggers an email notification. When the tenant is using a Zero Touch router and a compatible client device, the platform can also present a Seamless Account Alert.

Wi-Fi settings can be managed through the portal by the reseller or property owner, and they can also be managed by the tenant through the tenant login when that experience is enabled.

Yes, when the tenant-facing portal workflow is enabled. That lets the tenant handle Wi-Fi changes without requiring a support interaction for every SSID or password update.

No. Wi-Fi Traverse extends building-wide wireless coverage where the property needs it, but it does not replace the tenant-specific service structure.

No. Seamless Account Alerts are tied to Zero Touch router behavior and are not available on third-party routers.

Not by default. Custom inbound-port rules can be configured when needed, but normal tenant connections are not blocked from standard inbound traffic unless the location is provisioned behind private IP routing.

Yes, assuming the location was provisioned for public IP routing. Static IP assignment is handled in the tenant account settings, and the system can default to the next available unassigned public address if the address pool has been configured.

No, not when the tenant is provisioned with public routable IP space and the required service profile. Server and VPN behavior is primarily a function of the tenant’s own equipment and the upstream connection policy.

In most cases the tenant router will determine this automatically. When manual configuration is needed, 1492 is the common value, with 1488 used in some edge cases.

When a higher-priority tenant requests more bandwidth than is immediately available, the platform can reduce lower-priority tenants as needed to satisfy that request. It does not reduce any tenant below the guaranteed speed floor defined by their plan.

Yes. Priority can be reflected through the bandwidth plan structure so one tenant group receives higher priority than another. If you do that, the plan naming, positioning, and pricing should make that distinction clear.

Failover to a standby WAN can be supported when the primary connection failure can be detected cleanly, but the deployment has design constraints and may require custom configuration.

A common reason is that the tenant router is set to disconnect when idle. Changing the router from an on-demand mode to an always-on mode usually resolves that false-offline behavior.