Why we changed it
The previous behavior worked, but it had friction points many operators eventually run into:
- Redirect behavior depended on fixed assumptions instead of workspace-specific branding.
- Reminder links could carry context, but validation needed stronger guarantees.
- HTTPS traffic needed a policy-aware path, not just basic HTTP handling.
- Address-list state could drift when users were offline during enforcement.
- RADIUS users needed equivalent expired-profile behavior, not a separate weaker path.
The result was a system that mostly worked, but could still create edge-case confusion for staff and subscribers.
What's new in this update
1) Redirects now follow your workspace branding
Unpaid redirect targeting is now derived from each workspace's configured reminder host/settings instead of a single hardcoded network target.
That means branded and whitelabel environments behave the way customers expect: the reminder journey points to the workspaceâs own configured payment destination. If that destination is missing or can't be resolved safely, the system surfaces a clear operator-facing error instead of silently guessing.
2) Reminder links are now signed and context-bound
Payment reminder URLs now include a signed, expiring token tied to subscriber context (workspace, subscriber identity, and account identifiers). On access, token checks verify validity, expiration, and match against subscriber records.
In practical terms: links are harder to tamper with, safer to share in automated reminders, and more trustworthy during support escalations.
3) HTTPS enforcement is now policy-driven
The unpaid policy now handles HTTPS intentionally:
- HTTP reminder redirect remains in place for the captive payment path.
- For HTTPS, payment-related destinations are allowlisted.
- Non-approved encrypted traffic can be blocked while account status remains unpaid.
This mirrors how modern subscriber behavior actually works. Most users live inside HTTPS now, so unpaid policy has to account for that without breaking the payment route itself.
4) Address-list accuracy now survives reconnects and timing gaps
Expired profile handling now includes automatic on-up/on-down list maintenance so the address-list state stays accurate even when subscribers reconnect later, change sessions, or were offline when enforcement first triggered.
This reduces stale entries, reduces manual cleanup, and improves consistency between what staff sees and what the router is actually enforcing.
5) RADIUS users now get parity with local PPP flows
RADIUS subscribers now receive full expired-profile treatment through override policy and session control, including CoA-first behavior and a safe fallback path when live signaling is unavailable.
This closes an important operational gap: mixed environments (local PPP + RADIUS) now enforce unpaid policy more consistently, with clearer outcomes and fewer "why is this user different?" incidents.
6) Stronger regression coverage
We added focused regression tests around:
- state transition enforcement thresholds,
- reminder URL token generation/validation,
- redirect host and NAT resolution,
- router script generation and idempotency,
- RADIUS expired-policy and recovery flows.
That gives us better confidence during future iterations and lowers the risk of subtle billing-enforcement regressions.
What this means for operations teams
For support and NOC teams, this release should feel quieter over time:
- fewer redirect mismatches on branded domains,
- fewer edge-case unpaid sessions that bypass intent,
- fewer manual interventions to clean stale network state,
- clearer failure reasons when prerequisites are misconfigured.
For customers, the experience is straightforward: if service is restricted for non-payment, the path to resolve it is clearer, safer, and more consistent.
This update is part of a larger shift in philosophy: unpaid enforcement should be strict enough to protect the business, but humane enough to help customers recover quickly.
Blocking traffic is easy. Designing a recovery flow that works across branding, HTTPS, PPP, and RADIUS is the hard part.
That's the part we focused on here.